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I.  INTRODUCTION 

A.  PURPOSE 

With  the  progression  of  computer  systems  to  local  and  wide 
area  networks,  the  scope  of  computer  security  has  increased 
dramatically  over  the  past  two  decades.  The  ability  to  adequately 
safeguard  information  while  ensuring  resource  availability  is 
becoming  increasingly  challenging  to  system  administrators.  Given 
enough  time  and  resources,  any  system  may  be  broken  into  and  the 
information  accessed.  To  prevent  this  occurrence,  a  balance  must 
be  achieved  where  the  cost  of  breaking  into  the  system  outweighs 
the  benefits  derived  from  the  action.  The  National  Security  Agency 
(NSA)  developed  the  Trusted  Computer  Systems  Evaluation  Criteria 
(TCSEC)  to  provide  those  specifying  a  system  with  a  set  of 
expectations  regarding  the  assurance  of  policy  enforcement  and  to 
provide  vendors  with  a  set  of  standards  against  which  systems  could 
be  developed.  The  purpose  of  this  thesis  is  to  analyze  the  TCSEC 
and  its  applicability  to  a  Department  of  Defense  (DOD)  system  in  a 
networked  environment  using  current  technology. 

B .  OBJECTIVE 

The  intent  of  this  thesis  is  to  examine  the  TCSEC  and  its 
application  within  the  military  using  existing  commercial  products. 
During  the  past  decade,  much  discussion  has  taken  place  within  the 
DOD  regarding  the  requirements  for  government  computers  to  achieve 
specific  levels  of  trust.  At  the  beginning  of  the  1990' s,  "C2  by 
92"  was  a  phrase  that  was  frequently  used  in  computer  meetings  and 


seminars  throughout  the  DOD.  However,  the  lack  of  available 
products,  an  overall  lack  of  understanding  of  the  technology  and 
requirements,  politics,  and  a  lack  of  resources  prevented  that 
slogan  from  becoming  a  reality.  Over  the  past  few  years,  numerous 
vendors  have  been  striving  to  furnish  evaluated  products  which  will 
now  enable  the  Class  C2  level  of  trust  to  be  achieved. 

With  the  continuing  rise  in  the  number  of  networks  installed 
throughout  the  DOD  and  wider  connectivity  through  the  Internet,  the 
importance  of  establishing  a  "trusted"  system  is  rapidly  gaining 
acceptance.  A  thorough  analysis  of  the  Class  C2  certification 
process  using  a  major  network  operating  system  such  as  Windows  NT, 
is  an  excellent  way  to  determine  if  the  certification  is 
attainable.  Windows  NT  server  was  selected  for  this  evaluation  due 
to  its  increasing  popularity  among  Navy  commands. 

C.    RESEARCH  QUESTIONS 

In  order  to  achieve  the  objective  listed  above,  the  following 
research  questions  were  addressed: 

1.  What  are  the  requirements  to  achieve  a  Class  C2  level  of 
trust  in  a  computer  network? 

a.  How  are  computer  networks  certified  for  a  specific 
level  of  trust? 

b.  What  are  the  benefits  of  a  "trusted"  system? 

c.  What  are  the  limitations  of  certification? 

d.  How  does  a  Class  C2  certification  impact  life  cycle 
costs? 

e .  Can  a  network  be  connected  to  the  Internet  and 
still  provide  a  Class  C2  level  of  trust? 


2.  What  are  the  capabilities  of  Windows  NT  Server  3.51? 

a.  How  does  Windows  NT  support  the  Class  C2  level  of 
trust? 

b.  What  are  the  software's  security  limitations? 

c.  How  easily  does  Windows  NT  interface  with  other 
network  systems? 

D.  SCOPE  OF  THE  THESIS 

With  computers  and  the  information  they  maintain  increasingly 
under  attack,  more  people  are  beginning  to  take  computer  security 
seriously.  However,  many  still  do  not  fully  understand  what 
computer  security  is  and  why  it  is  so  important.  This  paper  begins 
by  identifying  some  basics  of  computer  security.  The  TCSEC 
requirements  are  discussed  in  detail  and  an  example  application  of 
the  criterion  is  presented.  In  conjunction  with  the  example 
application,  an  analysis  of  the  Windows  NT  Server  version  3.51 
Network  Operating  System  (NOS)  is  presented  for  both  security  and 
interoperability  issues.  Finally,  the  need  for  computer  security 
standards  for  the  government  and  the  responsiveness  of  today's 
market  to  meeting  those  needs  are  addressed. 

E.  RESEARCH  METHODOLOGY 

The  primary  methods  of  research  to  support  this  study  included 
an  in-depth  literature  search,  use  of  the  World  Wide  Web,  and 
correspondence  with  government  and  industry  representatives.  The 
literature  search  included  a  review  of  numerous  books,  magazine 
articles,  and  government  publications.  The  World  Wide  Web  was  used 
to  obtain  the  latest  information  on  the  certification  process  and 
to  gain  information  regarding  the  strengths  and  weaknesses  of  the 


Windows  NT  software.  Correspondence  with  officials  at  the  National 
Security  Agency  (NSA) ,  Microsoft,  and  other  federal  agencies  were 
used  to  obtain  information  on  test  results,  computer  security 
problems,  and  future  actions. 

F.    ORGANIZATION 

The  remainder  of  this  thesis  is  organized  as  follows: 

•  Chapter  II,  "Computer  Security,"  provides  a  general  overview 
of  computer  security.  The  goals  of  computer  security  are 
discussed  and  security  terms  are  defined.  The  chapter 
concludes  with  a  brief  description  of  the  evolution  of 
government  computer  security  initiatives. 

•  Chapter  III,  "The  Trusted  Computer  System  Evaluation 
Criteria  (TCSEC) , "  identifies  the  fundamental  security 
requirements  upon  which  the  evaluation  criterion  are  based. 
The  divisions  of  trust  and  terminology  used  with  the 
criterion  are  discussed  in  detail.  The  system  certification 
and  accreditation  process  is  described.  In  addition,  the 
product  evaluation  process  is  briefly  described. 

•  Chapter  IV,  "The  Trusted  Network  Interpretation  (TNI) , " 
compares  the  criterion  for  a  network  evaluation  to  the 
stand-alone  TCSEC  criterion.  The  differences  in  the 
evaluation  processes  are  briefly  described. 

•  Chapter  V,  "The  Falcon  LAN  -  Applying  the  TCSEC/TNI 
Criterion, "  presents  an  overview  of  the  network  installed  at 
the  Defense  Language  Institute  and  provides  an  in-depth 
analysis  of  Windows  NT  3.51  server.  Both  trust  and 
interoperability  issues  are  discussed. 

•  Chapter  VI,  "Conclusion  -  The  Pro's  and  Con's  of  Ensuring 
Trust,"  discusses  the  benefits  and  pitfalls  of  applying  the 
TCSEC  to  military  systems  today.  Issues  such  as  the  effect 
on  system  life  cycle  costs,  the  time  required  for  product 
evaluation,  and  the  market's  responsiveness  to  providing 
trusted  products  are  presented.  A  summary  of  research 
findings  and  recommendations  for  ensuring  the  DLI  LAN  is 
included. 


II.   COMPUTER  SECURITY 

With  today's  expanded  availability  of  computers,  an  increasing 
number  of  people  are  finding  themselves  vulnerable  to  the  perils  of 
the  information  age.  As  such,  the  topic  of  computer  security  is 
becoming  a  "hot  issue."  Computer  security  isn't  a  new  topic,  but 
one  that  has  existed  since  the  development  of  the  first  computer. 
What  is  new,  however,  is  the  broader  view  that  must  be  taken  to 
ensure  the  security  of  a  system  and  the  information  it  contains. 

Government  agencies  are  particularly  vulnerable  to  computer 
intrusions  due  to  the  nature  of  the  business  conducted  and  the  high 
profile  target  they  represent.  Since  the  late  1980' s,  several 
attacks  or  intrusions  have  become  well  publicized.  For  example, 
the  West  German  Computer  Club  (better  known  as  the  Chaos  Club) 
announced  in  1987  that  it  had  successfully  penetrated  NASA's 
computer  systems.  NASA  was  unaware  of  this  intrusion  until 
messages  began  appearing  on  their  system.  Also  in  1987,  a  75  cent 
accounting  error  alerted  Cliff  Stoll,  an  astronomer  turned  systems 
manager  at  Lawrence  Berkeley  Lab,  to  another  intrusion.  For  two 
years,  Dr.  Stoll  followed  the  intruder  as  he  tried  to  break  into 
over  450  computer  systems  (many  of  which  were  government  owned) . 
[Ref .  1]  Eventually  the  chase  led  to  a  small  group  of  West  German 
hackers  with  ties  to  the  Soviet  KGB.  Finally,  the  computer  worm  of 
1988  was  released  on  the  Internet  by  Robert  T.  Morris,  Jr.,  a 
Cornell  University  graduate  student,  on  November  2nd.  In  less  than 
48  hours,  the  worm  spread  throughout  the  network,  infecting  more 
than  2,100  computers.  Although  no  data  was  actually  destroyed,  the 


cost  of  fixing  the  systems  and  lost  work  hours  was  estimated  at 
over  $1  million.  [Ref .  2]  These  are  just  a  few  examples  of  where 
the  absence  of  secure  systems  and  computer  security  management 
techniques  have  resulted  in  serious  intrusions  and  why  improved 
approaches  to  computer  security  are  required. 

The  government  is  not  alone  with  respect  to  this  need.  With 
the  rapid  increase  in  the  number  of  computer  systems,  computer 
crime  has  become  a  major  threat  to  American  business.  "According 
to  the  Federal  Bureau  of  Investigation  (FBI) ,  computer  crime  is 
currently  the  most  expensive  form  of  commercial  crime  -  with  an 
average  cost  of  $450,000  per  theft.  This  represents  a  greater  risk 
to  corporations  than  fire  or  any  other  type  of  hazard."  [Ref.  3: 
p.  7]  In  addition,  the  FBI  estimates  the  total  figure  for  computer 
theft  may  range  as  high  as  $5  billion  per  year.  Compounding  the 
problem  is  the  lack  of  law  enforcement  attention  given  to  these 
crimes.  Estimates  indicate  that  up  to  90%  of  all  computer  crimes 
and  intrusions  are  never  reported  outside  of  the  organization.  Of 
those  that  are  reported,  only  a  fraction  of  the  cases  are  ever 
prosecuted.  [Ref.  3:  p.  8]  In  fact,  reports  concerning  computer 
crime  date  back  to  the  1940' s.  However,  it  wasn't  until  1966  that 
the  first  federal  prosecution  for  a  computer  crime  took  place.  The 
case  involved  the  use  of  a  computer  to  alter  the  records  of  a 
Minneapolis  bank.  [Ref.  4:  p.  16] 

There  are  several  reasons  why  computer  security  breaches  are 
not  publicized.  Government  system  intrusions  are  not  publicized  in 
an   attempt   to   limit   the   disclosure   of   security   holes   or 


vulnerabilities.  By  publicizing  such  information,  other  computer 
intruders  may  take  advantage  of  the  information  gained  to  penetrate 
additional  government  systems  with  the  same  or  similar  weaknesses. 

In  the  commercial  sector,  computer  intrusions  are  not 
publicized  for  fear  that  customers  would  lose  confidence  in  a 
company  and  take  their  business  elsewhere.  Legal  concerns  also 
keep  many  businesses  from  publicizing  computer  intrusions.  If  a 
company  maintains  information  on  customers  or  employees  that  is 
protected  under  the  Privacy  Act  of  1987,  the  company  may  be  held 
liable  for  any  unauthorized  disclosure  of  the  information.  This 
liability  could  further  increase  any  financial  losses  caused  by  the 
intrusion. 

The  use  of  "trusted"  computer  systems  is  one  approach  to 
dealing  with  problems  such  as  these.  However,  before  discussing 
the  criterion  used  to  achieve  trust  in  a  system,  an  overview  of 
computer  security  and  its  terminology  is  needed.  The  following 
sections  present  this  overview.  Although  not  every  aspect  of 
computer  security  is  presented  here,  the  reader  should  achieve  a 
good  basic  understanding  of  what  computer  security  is  and  what 
threats  it  is  trying  to  avoid. 

A.    GOALS  OF  COMPUTER  SECURITY 

Computer  security  focuses  on  the  achievement  of  three  main 
goals:  secrecy  (confidentiality),  integrity,  and  availability. 
Secrecy  ensures  information  including  unclassified,  private, 
sensitive,  and  classified  data,  is  not  disclosed  to  an  unauthorized 


person.  Integrity,  also  referred  to  as  accuracy,  means  the  system 
must  not  corrupt  the  information  maintained  on  it  or  permit  any 
unauthorized  changes  to  occur  through  either  accidental  or 
malicious  means.  Availability  ensures  the  system  is  operating 
efficiently  and  is  able  to  recover  quickly  and  completely  in  the 
event  of  a  disaster  or  attempted  disruption.  Loss  of  power, 
flooding,  fire,  and  unwelcomed  system  penetration  are  all  examples 
of  disasters  for  which  a  system  must  be  prepared.  If  users  are 
unable  to  access  the  computer  resources  needed,  then  a  denial  of 
service  has  occurred. 

In  addition  to  these  goals,  computer  networks  have  introduced 
two  additional  requirements:  authentication  and  nonrepudiation. 
Authentication  requires  the  address  of  a  message  (such  as 
electronic  mail)  to  be  identified  with  a  high  level  of  certainty 
that  the  address  is  correct.  In  a  sense,  it  is  an  aspect  of 
integrity.  Nonrepudiation  implies  that  neither  the  sender  nor 
receiver  of  a  message  can  deny  its  transmission. 

Achievement  of  any  or  all  of  these  goals  is  dependent  upon  the 
environment  in  which  the  system  is  operating.  In  some  cases,  one 
or  two  aspects  of  security  may  be  more  important  than  the  others . 
To  determine  the  services  which  are  needed,  the  goals  and 
environment  of  each  computer  system  must  be  assessed. 

B.    VULNERABILITIES  AND  THREATS 

A  security  assessment  typically  identifies  the  vulnerabilities 
and  threats  to  a  system.   A  vulnerability  indicates  a  point  where 
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a  system  is  susceptible  to  an  attack.  Examples  of  system 
vulnerabilities  include:  physical  threats,  natural  disasters, 
mechanical  breakdowns,  electronic  signals,  external  connections, 
and  people.  If  the  computer  system  is  a  network,  it  is  vulnerable 
at  any  point  where  it  contacts  another  network  or  system. 
Vulnerable  points  include  bridges,  routers,  and  modems,  as  well  as 
floppy  diskettes  and  portable  computers. 

A  threat  is  an  avenue  through  which  a  person  or  event  may 
exploit  a  vulnerability  to  adversely  affect  the  system.  Security 
experts  list  toll  fraud,  theft,  viruses,  disgruntled  employees, 
accidents,  and  ignorance  as  the  most  likely  threats  faced  by  system 
administrators  today.  [Ref .  4:  p  9]  In  terms  of  numbers,  errors 
and  accidents  typically  represent  the  largest  threat  to  a  network. 
As  Richard  Baker  noted  in  his  book  Network  Security:  How  to  Plan 
for  it  and  Achieve  It: 

One  of  the  biggest  obstacles  to  effective  computer 
security  today  is  an  epidemic  of  misplaced  emphasis. 
Corporations  spend  a  lot  of  time  and  money  buying  and 
installing  elaborate  computer  security  systems  to  protect 
themselves  from  well -publicized  outsiders  like  youthful 
invaders  and  virus  carriers .  They  do  next  to  nothing  to 
train  employees  to  make  regular  backups  or  to  avoid  that 
stereotype  of  computer  insecurity:  the  password  on  a 
sticky  note  attached  to  the  monitor.  By  one  estimate  - 
really  a  guess,  but  a  reasonable  one  -  system 
administrators  who  accidentally  destroy  data  by  punching 
the  wrong  key  outnumber  crazed  hackers  by  at  least  10  to 
1.   [Ref.  4] 

Lack  of  training  is  not  the  only  threat  from  the  users  of  a 
system.  It  is  estimated  "that  as  many  as  80  percent  of  system 
penetrations  are  conducted  by  fully  authorized  users  who  abuse 


their  access  privileges  to  perform  unauthorized  functions."  [Ref . 
3:  p.  16]  The  Justice  Department  conducted  an  analysis  of  computer 
abuse  cases  and  identified  the  following  functions  as  the  points 
where  data  processing  systems  tended  to  be  the  most  vulnerable: 
[Ref.  4] 

•  Poor  controls  over  data  handling 

•  Weak  or  missing  physical  controls 

•  Inadequate  procedural  controls 

•  Weak  ethical  standards 

•  Poor  programming  practices 

•  Operating  system  weaknesses 

•  Lack  of  user  identification 

•  Inadequate  control  over  storage  media 

A  "newspaper  effect"  within  some  organizations  causes  many 
system  administrators  to  focus  on  the  highly  publicized  external 
threats  such  as  hackers  and  viruses.  As  a  result,  too  little 
attention  is  given  to  basic  countermeasures  such  as  backups  and 
passwords,  which  can  prevent  more  serious  problems  from  within  the 
organization. 

Networks  in  particular,  suffer  from  an  additional  weakness 
caused  by  system  administrators  focusing  on  the  end  system  and  not 
the  network  as  a  whole.  For  example,  many  network  administrators 
expend  much  effort  and  resources  to  protect  the  hosts  on  the 
network,  yet  pay  little  or  no  attention  to  the  overall  network. 
This  is  because  it  is  generally  easier  to  protect  the  hosts  rather 

10 


than  the  entire  network,  and  intruders  are  more  likely  to  go  after 
the  data  on  the  host.  However,  there  are  sound  reasons  for 
protecting  the  overall  network.  By  focusing  on  the  host  alone,  the 
entire  network  may  be  subject  to  vulnerabilities  that  are 
overlooked.  For  example,  an  intruder  may  be  able  to  divert 
transmitted  data  to  an  off -site  host  for  examination  or  to  search 
for  passwords.  Human  error,  in  the  form  of  a  misconf igured  host 
could  lead  to  a  degradation  in  service  for  network  users.  Or,  a 
denial  of  service  attack  may  be  generated  without  the  attacker  ever 
penetrating  the  system.  By  focusing  on  the  entire  network, 
vulnerabilities  such  as  these  should  be  identified. 


C.    ATTACKS  ON  COMPUTER  NETWORKS 

Attacks  on  a  computer  network  may  be  passive  or  active. 
Passive  attacks  include  eavesdropping  and  monitoring  transmissions 
to  gather  information.  The  information  may  be  gained  either 
directly  from  the  contents  of  a  message  or  indirectly  through 
traffic  analysis.  Traffic  analysis  is  a  more  subtle  form  of 
passive  attack,  but  one  which  should  not  be  neglected  when  securing 
a  system.  Usually  passive  attacks  are  difficult  to  detect  since 
information  is  not  changed  in  any  way.  Most  security  techniques  to 
guard  against  such  attacks  are  preventive  in  nature  rather  than 
geared  toward  detection. 

Unlike   passive   attacks,   active   attacks   involve   the 
modification  of  information  or  the  insertion  of  false  information. 
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Active  attacks  are  typically  divided  into  four  main  categories: 
masquerade,  replay,  modification,  and  denial  of  service. 

•  A  masquerade  occurs  when  one  person  or  group  pretends  to  be 
someone  else.  (A  masquerade  normally  includes  another  form 
of  active  attack  as  well.) 

•  A  replay  occurs  when  the  contents  of  a  message  is  captured 
and  then  retransmitted  to  produce  an  unauthorized  effect. 

•  If  part  of  a  legitimate  message  is  altered,  delayed,  or 
reordered,  then  a  modification  attack  has  taken  place.  The 
modification  category  also  includes  attacks  by  malicious 
software  which  alter  the  contents  of  a  file. 

•  If  the  normal  use  or  management  of  a  system  is  prevented  or 
constrained  in  any  way,  then  a  denial  of  service  attack  has 
been  implemented.  A  denial  of  service  attack  can  also 
result  from  the  introduction  of  malicious  software  which 
consumes  system  resources. 

Unlike  passive  attacks,  active  attacks  are  generally  difficult  to 
prevent.  The  goal  in  dealing  with  active  attacks  is  normally  to 
detect  them  and  then  recover  from  any  disruption  or  delays  they  may 
have  caused . 

Using  the  three  main  goals  of  computer  security  (secrecy, 
integrity,  and  availability) ,  attacks  on  computer  systems  fall 
under  four  main  categories:  interruption,  interception, 
modification,  and  fabrication.   [Ref .  2:  pp.  7-8] 


•  Interruption  is  an  attack  on  the  availability  of  a  system  in 
which  part  of  the  system  is  either  destroyed  or  becomes 
unavailable . 

•  Interception  occurs  when  an  unauthorized  entity  gains  access 
to  the  system,  attacking  the  system's  confidentiality. 
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•  If  an  unauthorized  person  gains  access  and  tampers  with  the 
system  or  the  information  it  maintains,  then  a  modification 
has  occurred  and  the  system's  integrity  has  been  attacked. 

•  A  fabrication  has  occurred  if  an  unauthorized  user  inserts 
false  information  into  the  system,  affecting  its 
authenticity. 


D .    COUNTERMEASURES 

Once  the  vulnerabilities  and  threats  to  a  system  have  been 
determined,  specific  countermeasures  to  prevent  or  recover  from  the 
effects  of  these  risks  must  be  implemented.  There  are  numerous 
types  of  countermeasures  available.  Computer  security 
countermeasures  focus  on  the  operating  system  features  which 
control  access  to  a  system,  and  communications  security  measures 
are  used  to  protect  transmitted  information.  Countermeasures 
associated  with  communications  security  are  used  on  computer 
networks  to  control  access  to  the  network  computers  from  both 
internal  and  external  connections.  Finally,  physical  security 
countermeasures  are  used  to  protect  a  computer  system  from  natural 
disasters  and  intruders.  Typically,  countermeasures  of  all  three 
forms  will  be  required  for  most  computer  systems. 

"It  is  anticipated  that  by  the  year  2000,  information  will 
account  for  a  larger  portion  of  the  U.S.  gross  national  product 
than  manufactured  products  and  other  physical  commodities."  [Ref . 
1]  With  this  increased  reliance  on  information,  the  security 
mechanisms  required  to  ensure  the  confidentiality,  integrity,  and 
availability  of  the  information  must  be  widely  implemented. 
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Driving  these  security  requirements  is  the  U.S.  government. 
Each  year,  the  government  classifies  approximately  6.8  billion 
pieces  of  information  which  must  be  protected.  [Ref .  3:  p.  18]  To 
ensure  the  information  is  protected  uniformly  throughout  the 
government,  standards  were  required.  The  development  of  standards 
began  in  1965  with  the  passing  of  the  Brooks  Act.  Since  then, 
numerous  government  efforts  have  been  aimed  at  achieving  a  uniform 
management  of  federal  Information  Technology  (IT)  resources.  As  a 
result,  a  foundation  has  been  formed  over  the  past  30  years  for  all 
aspects  of  IT  management . 

E.    THE  EVOLUTION  OF  GOVERNMENT  COMPUTER  SECURITY  INITIATIVES 

Computer  security  efforts  began  in  the  1950 's  when  the  first 
TEMPEST  security  standard  was  developed.  TEMPEST  refers  to 
"technology  that  shields  computer  equipment  to  keep 
electronmagnetic  emissions  from  being  intercepted  and  deciphered  by 
eavesdroppers."  [Ref.  3:  p.  17]  Also  during  the  1950' s  the  U.S. 
Communications  Security  (COMSEC)  Board  was  established.  Composed 
of  representatives  from  various  branches  of  the  government,  COMSEC 
was  given  the  oversight  responsibility  for  protecting  classified 
information.  In  addition,  some  early  system  designs  were  developed 
with  security  features  built-in. 

It  wasn't  until  the  1960's,  however,  that  public  awareness  was 
raised  concerning  computer  security.  During  that  decade,  numerous 
initiatives  were  started  by  the  Department  of  Defense  (DOD) ,  the 
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National  Security  Agency   (NSA) ,   and  the  National  Bureau  of 
Standards  (NBS) .   Specifically: 

•  The  Automatic  Data  Processing  Equipment  Act  (better  known  as 
the  Brooks  Act)  was  passed  by  Congress  in  1965.  As  a 
consequence  of  this  act,  the  NBS  was  placed  in  charge  of 
researching  and  developing  standards  for  the  procurement  and 
use  of  federal  computer  systems.  Initially,  NBS  efforts 
were  focused  on  evaluating  the  existing  systems  and  studying 
the  government's  computer  security  requirements.  During  the 
1970' s,  NBS  efforts  shifted  to  developing  computer  security 
standards  in  two  distinct  areas:  building  and  evaluating 
secure  systems  and  cryptography.  Several  seminars  and 
workshops  were  held  to  define  the  problems  facing  federal 
computer  systems  and  to  develop  solutions  to  these  problems. 
As  a  result,  numerous  reports  were  generated  with  the 
conclusion  that  computer  security  required  attention  in 
three  areas:  policy,  mechanisms,  and  assurance.  Policy  was 
needed  to  state  the  security  rules  required  to  ensure  the 
security  of  sensitive  information.  Hardware  and  software 
mechanisms  would  be  used  to  enforce  the  policy,  and  the 
enforcement  should  provide  a  reasonable  level  of  assurance 
that  the  policy  was  supported  even  when  a  computer  system 
was  subjected  to  threats. 

•  To  develop  the  policy,  mechanisms,  and  required  assurance 
proposed  by  the  NBS  efforts,  three  specific  actions  were 
recommended.  First,  a  detailed  computer  security  policy  for 
sensitive  information  was  needed.  Second,  a  formal  security 
evaluation  and  accreditation  process  was  required  that  would 
include  the  publication  of  a  list  of  approved  products  for 
handling  sensitive  information;  and  third,  a  standard, 
formalized  technical  means  of  evaluating  the  overall 
security  of  a  system  was  needed.  The  task  of  developing  an 
initial  set  of  computer  security  evaluation  criterion  was 
assigned  to  the  Mitre  Corporation.  To  fulfill  the  other 
tasks,  the  Office  of  the  Secretary  of  Defense  sponsored 
several  public  seminars.  As  a  result  of  the  seminars,  the 
NSA  was  placed  in  charge  of  increasing  the  use  of  trusted 
information  security  products  within  DOD. 


In  1967,  DOD  assembled  a  task  force  within  the  Advanced 
Research  Project  Agency  (ARPA)  to  study  the  potential 
threats  to  DOD  computer  systems  and  information.  The  task 
force  worked  for  two  years  examining  computer  systems  and 
networks,  identifying  vulnerabilities  and  threats,  and 
establishing  methods  for  protecting  and  controlling  access 
to  government  computers  and  information.   In  1970,  the  task 
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force  published  its  report,  Security  Controls  for  Computer 
Systems,  which  has  been  viewed  by  many  as  a  landmark 
publication  in  the  history  of  computer  security.  [Ref .  3: 
p.  28]  The  research  that  followed  this  report  led  to 
numerous  programs  aimed  at  protecting  classified  information 
and  setting  computer  security  standards.  In  1972,  a 
directive  and  an  accompanying  manual  was  issued  by  DOD 
establishing  a  consistent  policy  for  computer  controls  and 
techniques . 

The  initiatives  started  during  the  1960 's  continued  into  the 
1970' s.  Government  and  industry  sponsored  "tiger  teams"  were 
organized  to  attempt  to  break  into  computer  systems  in  order  to 
find  security  holes  and  then  correct  them.  The  teams  were 
effective  at  finding  numerous  security  gaps.  However,  it  soon 
became  apparent  that  the  only  means  of  "guaranteeing"  system 
security  was  to  design  verifiable  protection  mechanisms  into  the 
systems  from  the  beginning. 

In  addition  to  the  tiger  teams,  a  number  of  research  projects 
aimed  at  identifying  security  requirements,  formulating  security 
policy  models,  and  defining  recommended  guidelines  and  controls 
were  initiated.  As  a  result,  several  concepts  and  reports  were 
produced.  For  example,  the  concept  of  a  reference  monitor  was 
introduced  by  James  P.  Anderson.  The  reference  monitor  is  used  to 
"enforce  the  authorized  access  relationship  between  subjects  and 
objects  of  a  system."  [Ref.  3:  p.  30]  Also  during  the  1970' s, 
David  Bell  and  Leonard  LaPadula  developed  the  first  mathematical 
model  of  DOD  security  policy  which  has  become  known  as  the  Bell  and 
LaPadula  model .  Both  the  reference  monitor  concept  and  the  Bell 
and  LaPadula  model  were  included  in  later  government  computer 
security  standards. 
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Most  of  the  government  efforts  aimed  at  developing  a  secure 
system  during  the  1970 's  were  pointed  toward  the  formation  of  a 
security  kernel .  The  kernel  is  part  of  the  operating  system  which 
controls  access  to  system  resources.  An  initiative  funded  by  the 
Air  Force  eventually  led  to  the  development  of  security  mechanisms 
for  the  Multiplexed  Information  and  Computing  Service  (MULTICS) 
system.  MULTICS  was  a  large-scale,  highly  interactive  system  that 
offered  both  hardware  and  software  security  features.  Users  with 
different  security  clearances  could  simultaneously  access  different 
levels  of  classified  information.  MULTICS  was  extremely  important 
because  it  provided  the  foundation  for  the  later  development  of 
other  secure  systems. 

In  an  attempt  to  focus  national  attention  and  resources  on 
computer  security,  the  DOD  Computer  Security  Initiative  was 
announced  in  1977.  Under  this  initiative,  a  series  of  seminars 
were  held  with  participants  from  both  government  and  industry 
addressing  the  following  questions:   [Ref .  3:  p.  32] 

•  Are  secure  computer  systems  useful  and  feasible? 

•  What  mechanisms  should  be  developed  to  evaluate  and  approve 
secure  computer  systems? 

•  How  can  computer  vendors  be  encouraged  to  develop  secure 
computer  systems? 

To  expand  upon  the  work  completed  under  the  DOD  Computer 
Security  Initiative,  NSA  created  the  DOD  Computer  Security  Center 
(CSC)  on  2  January  1981.  During  the  following  years,  the  role  of 
the  CSC  was  modified  to  encompass  all  federal  systems  and  the  name 
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changed  to  the  National  Computer  Security  Center  (NCSC)  in  August 
1985.  The  center's  role  since  its  beginning  has  been  to  evaluate 
and  promote  the  use  of  trusted  systems  in  the  federal  government. 
As  such,  the  NCSC  has  played  a  vital  role  in  the  field  of  computer 
security  over  the  years . 

In  August  1983,  the  NCSC  published  the  Trusted  Computer  System 
Evaluation  Criteria  (TCSEC)  ,  also  known  as  the  Orange  Book.  The 
publication  was  based  on  the  criterion  developed  by  the  Mitre 
Corporation  and  other  earlier  security  developments  such  as  the 
Bell-Lapadula  Model.  [Ref .  3:  p.  35]  Since  its  publication,  the 
TCSEC  has  become  "the  Bible  of  secure  system  development," 
describing  the  criterion  used  to  assess  the  level  of  trust  that  can 
be  placed  on  a  particular  computer  system.  Products  are  submitted 
to  the  NCSC  by  vendors  requesting  an  evaluation  for  a  specified 
level  of  trust.  Upon  the  successful  completion  of  the  evaluation 
process,  the  products  are  added  to  the  center's  Evaluated  Products 
List. 

Since  the  issuance  of  the  TCSEC,  NCSC  has  also  provided  a 
series  of  additional  publications  which  are  used  to  interpret 
various  aspects  of  the  criterion  including  network  communications, 
security  subsystems,  and  specialty  products.  These  publications 
are  referred  to  as  the  Rainbow  Series . 

The  field  of  computer  security  has  continued  to  develop  since 
the  publication  of  the  TCSEC.  However,  since  the  focus  of  this 
thesis  deals  with  the  TCSEC  and  its  application  today,   the 
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discussion  of  computer  security  developments  will  stop  at  this 
point  so  the  TCSEC  can  be  discussed  in  further  detail . 
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III.  THE  TRUSTED  COMPUTER  SYSTEM  EVALUATION  CRITERIA 

The  Trusted  Computer  System  Evaluation  Criteria  (TCSEC) ,  or 
Orange  Book,  was  first  published  by  the  National  Computer  Security 
Center  (NCSC)  in  August  1983.  In  1985,  the  original  publication 
was  revised  slightly  and  reissued  in  December.  Since  its  initial 
publication,  the  TCSEC  has  provided  the  ground  rules  for  evaluating 
the  level  of  trust  that  can  be  given  to  a  specific  computer  system. 
As  Russell  and  Gangemi  state  in  Computer  Security  Basics,  the  TCSEC 
"effectively  makes  security  a  measurable  commodity  so  a  buyer  can 
identify  the  exact  level  of  security  required  for  a  particular 
system,  application,  or  environment."  [Ref .  3] 

The  TCSEC  measures  trust  through  two  perspectives  -  security 
policy  and  assurance.  Security  policy  provides  the  rules  that  are 
to  be  enforced  by  a  system's  security  features.  Assurance  refers 
to  the  trust  that  can  be  placed  in  a  system,  and  includes  the 
methods  used  to  "prove"  the  security  features  have  been  developed, 
tested,  documented,  maintained,  and  delivered  to  a  customer.  At 
the  lower  levels,  assurance  is  gained  mostly  through  the  testing  of 
the  system.  At  the  higher  levels,  assurance  is  derived  more  from 
a  rigorous  approach  to  system  design  and  implementation. 

The  TCSEC  defines  four  broad  divisions  of  security  protection 
which,  in  increasing  order,  are:  D  -  Minimal  Security,  C  - 
Discretionary  Protection,  B  -  Mandatory  Protection,  and  A  - 
Verified  Protection.  Each  division  is  further  refined  into  one  or 
more  numbered  classes.  The  higher  the  number,  the  greater  the 
level  of  protection  afforded  within  the  division. 
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Each  class  is  defined  by  a  specific  set  of  criterion  that  must 
be  met  to  be  awarded  the  rating  of  that  class.  The  criteria  fall 
into  four  main  categories:  security  policy,  accountability, 
assurance,  and  documentation.  The  levels  of  trust  are  cumulative 
with  each  building  upon  the  requirements  of  lower  classes.  A  brief 
description  of  each  division  is  provided  in  section  B  of  this 
chapter. 

A.    FUNDAMENTAL  SECURITY  REQUIREMENTS 

The  TCSEC  dictates  that  trusted  systems  will  control  access  to 
all  information  through  the  use  of  specific  security  features. 
These  features  must  ensure  that  only  authorized  users  (or  processes 
operating  on  behalf  of  the  users)  will  have  access  to  the 
information.  Furthermore,  the  access  permitted  will  be  based  on 
the  capabilities  (i.e.,  read,  write,  create,  delete)  that  have  been 
authorized  for  the  user.  To  ensure  the  security,  six  fundamental 
requirements  were  created:  [Ref .  5:  pp.  3-4] 

•  Requirement  1  -  SECURITY  POLICY  -  There  must  be  an  explicit 
and  well-defined  security  policy  enforced  by  the  system. 

Given  identified  subjects  and  objects,  there  must  be  a  set 
of  rules  that  are  used  by  the  system  to  determine  whether  a 
given  subject  can  be  permitted  to  gain  access  to  a  specific 
object.  Computer  systems  of  interest  must  enforce  a 
mandatory  security  policy  that  can  effectively  implement 
access  rules  for  handling  sensitive  (e.g.,  classified) 
information.  These  rules  include  requirements  such  as:  No 
person  lacking  proper  personnel  security  clearance  shall 
obtain  access  to  classified  information.  In  addition, 
discretionary  security  controls  are  required  to  ensure  that 
only  selected  users  or  groups  of  users  may  obtain  access  to 
data  (e.g.,  based  on  a  need-to-know). 
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•  Requirement  2  -  MARKING  -  Access  control  labels  must  be 
associated  with  objects.  In  order  to  control  access  to 
information  stored  in  a  computer,  according  to  the  rules  of 
a  mandatory  security  policy,  it  must  be  possible  to  mark 
every  object  with  a  label  that  reliably  identifies  the 
object's  sensitivity  level  (e.g.,  classification),  and/or 
the  modes  of  access  accorded  those  subjects  who  may 
potentially  access  the  object. 


•  Requirement  3  -  IDENTIFICATION  -  Individual  subjects  must  be 
identified.  Each  access  to  information  must  be  mediated 
based  on  who  is  accessing  the  information  and  what  classes 
of  information  they  are  authorized  to  deal  with.  This 
identification  and  authorization  information  must  be 
securely  maintained  by  the  computer  system  and  be  associated 
with  every  active  element  that  performs  some 
security- relevant  action  in  the  system. 


•  Requirement  4  -  ACCOUNTABILITY  -  Audit  information  must  be 
selectively  kept  and  protected  so  that  actions  affecting 
security  can  be  traced  to  the  responsible  party.  A  trusted 
system  must  be  able  to  record  the  occurrences  of 
security- relevant  events  in  an  audit  log.  The  capability  to 
select  the  audit  events  to  be  recorded  is  necessary  to 
minimize  the  expense  of  auditing  and  to  allow  efficient 
analysis.  Audit  data  must  be  protected  from  modification 
and  unauthorized  destruction  to  permit  detection  and 
after-the-fact  investigations  of  security  violations. 


•  Requirement  5  -  ASSURANCE  -  The  computer  system  must  contain 
hardware/ software  mechanisms  that  can  be  independently 
evaluated  to  provide  sufficient  assurance  that  the  system 
enforces  requirements  1  through  4  above.  In  order  to 
assure  that  the  four  requirements  of  Security  Policy, 
Marking,  Identification,  and  Accountability  are  enforced  by 
a  computer  system,  there  must  be  some  identified  and  unified 
collection  of  hardware  and  software  controls  that  perform 
those  functions.  These  mechanisms  are  typically  embedded  in 
the  operating  system  and  are  designed  to  carry  out  the 
assigned  tasks  in  a  secure  manner.  The  basis  for  trusting 
such  system  mechanisms  in  their  operational  setting  must  be 
clearly  documented  such  that  it  is  possible  to  independently 
examine  the  evidence  to  evaluate  their  sufficiency. 


•  Requirement  6  -  CONTINUOUS  PROTECTION  -  The  trusted 
mechanisms  that  enforce  these  basic  requirements  must  be 
continuously  protected  against  tampering  and/or  unauthorized 
changes.   No  computer  system  can  be  considered  truly  secure 
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if  the  basic  hardware  and  software  mechanisms  that  enforce 
the  security  policy  are  themselves  subject  to  unauthorized 
modification  or  subversion.  The  continuous  protection 
requirement  has  direct  implications  throughout  the  computer 
system's  life-cycle. 

Requirements  1  and  2  deal  with  a  system's  policy,  3  and  4  reflect 

the  system's  accountability,  and  5  and  6  deal  with  the  level  of 

assurance  offered  by  a  system.   It  was  from  these  six  requirements 

that  the  actual  evaluation  criterion  were  derived. 

B.    DIVISIONS  OF  TRUST 

1.  Division  D:   Minimal  Protection 

Division  D  contains  only  one  class  and  is  reserved  for  those 
systems  which  fail  to  meet  a  higher  assurance  level .  Given  the 
amount  of  time  and  money  required  for  a  vendor  to  submit  a  system 
for  evaluation,  systems  are  normally  not  submitted  for  this  rating. 
However,  if  a  system  fails  to  meet  the  Class  Cl  requirements,  it 
may  receive  a  Class  D  rating. 

2.  Division  C:   Discretionary  Protection 

Division  C  consists  of  two  classes,  Cl  and  C2 .  Systems 
certified  at  this  division  of  trust  must  provide  discretionary  or 
need-to-know  protection  as  well  as  audit  capabilities.  The  design 
of  a  Trusted  Computing  Base  (TCB)  is  central  to  systems  evaluated 
at  this  level  and  higher.  The  TCB  provides  a  separation  of  users 
and  data  so  the  access  controls  may  be  implemented. 

Class  Cl  systems  provide  discretionary  security  protection  by 
providing  a  separation  between  users  and  data.  The  environment  in 
which  a  Cl  system  is  used  is  expected  to  be  one  of  cooperation  with 
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users  processing  data  at  the  same  level  of  sensitivity.  At  the  CI 
level,  users  are  permitted  to  log  into  the  system  as  a  group,  using 
a  shared  password. 

Class  C2  is  referred  to  as  the  Controlled  Access  Protection 
class.  Systems  certified  at  this  level  provide  access  control  that 
is  granularized  to  the  individual  user.  Login  procedures,  auditing 
capabilities,  and  resource  isolation  all  hold  users  individually 
accountable  for  their  actions.  In  a  Class  C2  environment,  each 
user  must  log  into  the  system  using  a  unique  password  or 
identifier.  Shared  passwords  are  not  permitted.  In  addition, 
object  reuse  features  must  be  present  to  prevent  the  unauthorized 
disclosure  of  information. 

3.    Division  B:   Mandatory  Protection 

The  TCB  is  used  to  maintain  the  integrity  of  sensitivity 
labels  which  are  used  to  enforce  a  set  of  mandatory  access  control 
rules.  The  sensitivity  labels  must  be  used  with  all  major  data 
structures  in  the  system.  As  part  of  the  product  evaluation,  the 
system  developer  must  provide  the  security  policy  model  and 
specifications  on  which  the  TCB  is  based.  In  addition,  it  must  be 
clear  that  the  reference  monitor  concept  was  used  in  the  design  of 
the  system. 

The  B  division  consists  of  three  separate  classes.  Class  Bl 
introduces  Mandatory  Access  Control  (MAC)  through  the  addition  of 
labels.  An  informal  statement  of  the  security  policy  model,  data 
labeling,  and  MAC  for  named  subjects  and  objects  must  be  included 
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in  the  system  design.   Sensitivity  labeling  must  also  be  provided 
for  all  exported  information. 

The  differences  between  Classes  C2  and  Bl  protection  are 
minimal.  Theodore  M.P.  Lee  presents  an  interesting  analysis  of 
these  ratings  for  systems  operating  in  compartmented  mode.  With 
compartmented  mode,  some  system  users  are  not  formally  authorized 
access  to  all  of  the  information  maintained  on  the  system.  In  his 
paper  "A  Note  on  Compartmented  Mode:  To  B2  or  not  B2?",  Mr.  Lee 
recommends  a  rating  of  B2  or  higher  for  compartmented  mode  systems . 
[Ref.  6] 

Class  B2  provides  structured  protection  by  building  on  the 
capabilities  provided  in  Class  Bl .  Class  B2  is  the  first  level 
where  the  reference  monitor  concept  is  substantially  implemented 
into  the  system  design.  The  TCB  must  be  based  on  a  clearly  defined 
and  documented  formal  security  model  that  provides  both 
discretionary  and  mandatory  access  control  to  all  levels  of  the 
system.  The  TCB  is  carefully  structured  into  protection-critical 
and  non-protection-critical  elements  with  a  well  defined  interface. 
The  system  must  be  relatively  resistant  to  penetration  and  covert 
channels  must  be  addressed.  Products  submitted  for  evaluation  at 
this  level  are  subjected  to  a  more  thorough  test  and  review  than 
those  submitted  for  lower  classifications. 

Class  B3  provides  security  domains  with  the  reference  monitor 
concept  fully  enforced.  The  system  must  be  designed'  with 
complexity  minimized  and  non-essential  code  excluded.  Support  is 
provided  to  the  system  administrator  through  expanded  auditing 
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capabilities  and  system  recovery  procedures.  The  search  for  covert 
channels  is  also  expanded  to  include  both  storage  and  timing 
channels.  Should  a  system  failure  occur,  trusted  recovery  features 
must  be  implemented  to  ensure  the  recovery  of  resources  without  a 
compromise  of  data.  Finally,  more  extensive  documentation  of  the 
system  security  features  is  required  for  a  Class  B3  evaluation. 

4.    Division  A:   Verified  Protection 

Formal  security  verification  methods  are  used  to  ensure  the 
system's  mandatory  and  discretionary  access  controls  will 
effectively  protect  classified  and  sensitive  information.  This 
level  requires  extensive  documentation  to  be  submitted  during  the 
evaluation  process.  Class  Al,  verified  design,  is  the  only  class 
currently  listed  in  this  division.  Functionally,  the  requirements 
for  Al  are  equivalent  to  those  for  a  B3  certification,  with  the 
addition  of  trusted  distribution.  Trusted  distribution  provides 
control  over  the  integrity  of  the  data  describing  the  TCB . 
Procedures  must  be  implemented  to  ensure  any  data  updates 
distributed  to  customers  precisely  match  the  master  copies. 

The  main  difference  between  the  B3  and  Al  classes  results  from 
the  analysis  and  verification  techniques  used  on  the  formal  design. 
The  techniques  result  in  a  higher  level  of  assurance  that  the  TCB 
is  correctly  implemented.  In  addition,  more  stringent 
configuration  management  is  required. 
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c. 


ENSURING  TRUST 


Given  enough  time  and  resources,  any  computer  system  can  be 
penetrated  or  subverted  regardless  of  the  trust  engineering  and 
security  features  that  are  provided.  Therefore,  the  TCSEC  measures 
the  level  of  trust  that  can  be  provided  by  a  system  to  ensure  the 
system  will  enforce  the  security  policy  over  time.  The  TCSEC 
defines  a  trusted  system  as  one  "that  employs  sufficient  hardware 
and  software  integrity  measures  to  allow  its  use  to  simultaneously 
process  a  range  of  sensitive  unclassified  or  classified  (e.g., 
confidential  through  top  secret)  information  for  a  diverse  set  of 
users  without  violating  access  privileges."  [Ref .  5]  "Inherent  to 
the  concept  of  trust  is  some  assurance  that  the  trusted  person  or 
entity  possesses  the  required  strength,  capability,  and  integrity 
to  merit  that  trust."  [Ref.  7:  p.  13]  The  trust  is  actually  built 
from  the  bottom  or  hardware  level  up,  with  each  layer  "trusting" 
the  lower  layers  to  perform 
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Figure  1:   Trust  Hierarchy  in  a  Computer  System  [Ref  7] 
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their  services  reliably  and  accurately.  Figure  1  was  taken  from 
NCSC's  Assessing  Controlled  Access  Protection  [Ref .  7]  and 
describes  this  layering  of  trust  graphically. 

Several  different  concepts  are  used  in  order  to  achieve  these 
various  levels  of  trust.  The  following  sections  provide  a  brief 
synopsis  of  the  major  concepts  used  throughout  the  TCSEC. 

1.    Trusted  Computing  Base  (TCB) 

Central  to  the  idea  of  a  trusted  system  is  the  concept  of  a 
Trusted  Computing  Base  (TCB)  .  The  TCB  is  used  to  refer  to  the 
mechanisms  that  enforce  a  system's  security  and  is  defined  as: 

The  totality  of  protection  mechanisms  within  a  computer 
system  -  including  hardware,  firmware,  and  software  -  the 
combination  of  which  is  responsible  for  enforcing  a 
security  policy.  It  creates  a  basic  protection 
environment  and  provides  additional  user  services 
required  for  a  trusted  computer  system.  The  ability  of 
a  trusted  computing  base  to  correctly  enforce  a  security 
policy  depends  solely  on  the  mechanisms  within  the  TCB 
and  on  the  correct  input  by  system  administrative 
personnel  of  parameters  (e.g.,  a  user's  clearance) 
related  to  the  security  policy.  [Ref.  5] 

Normally  the  TCB  does  not  include  the  entire  system.  Part  of  the 
analysis  of  any  product  submitted  for  evaluation  is  the 
identification  of  the  TCB  (i.e.,  the  architecture,  assurance 
mechanisms,  and  security  features  that  work  together  to  form  the 
TCB) .  Once  identified,  the  TCB  is  evaluated  to  determine  how  well 
it  is  protected  from  tampering  and  interference. 

The  size  and  structure  of  the  TCB  will  vary  across  the 
different  classes  of  trust.  At  the  Class  C2  level,  the  TCB  will 
normally  be  large,  dispersed,  and  unstructured.   This  presents  a 
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challenge  to  both  evaluators  and  system  administrators  for  assuring 
and  maintaining  the  system's  security.  As  a  system  progresses  up 
the  trust  hierarchy,  the  TCB  typically  becomes  smaller  and  more 
structured.  At  the  B2  level,  the  TCB  may  still  be  large.  However, 
due  to  increased  structure  in  the  software  engineering  designs  and 
use  of  hardware  protection  features,  the  modularity  increases, 
resulting  in  a  system  that  is  easier  to  understand,  evaluate,  and 
maintain.  Finally,  systems  meeting  the  B3  and  Al  levels  of  trust 
generally  have  TCB's  which  are  small,  layered,  and  highly 
structured  permitting  more  rigorous  testing  and  evaluation  to  be 
conducted. 

2.    Subjects  and  Objects 

The  terms  subjects  and  objects  are  typically  used  to  refer  to 
the  entities  of  a  computer  system.  Subjects  are  active  entities 
such  as  people,  processes,  or  devices,  which  can  cause  information 
to  flow  within  the  system  or  can  cause  the  state  of  the  system  to 
change . 

Objects  are  passive  devices  that  contain  or  receive 
information.  Files,  directories,  directory  trees,  records, 
segments,  printers,  network  nodes,  clocks,  keyboards,  and 
processors  are  all  examples  of  objects.  Access  to  an  object  is 
associated  to  a  subject  through  a  right  or  access  mode.  When  a 
subject  is  authorized  access  to  an  object,  access  is  also 
authorized  to  the  information  contained  in  the  object.  The  set  of 
objects  that  a  subject  is  able  to  access  is  referred  to  as  the 
subject's  domain. 
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3 .    Reference  Monitor 

The  reference  monitor  is  used  to  enforce  "the  authorized 
access  relationships  between  subjects  and  objects  of  a  system." 
[Ref .  3:  p.  107]  The  reference  monitor  serves  as  an  interface 
between  a  subject  and  the  object  to  which  the  subject  seeks  access. 
When  a  request  is  made,  the  reference  monitor  accepts  the  request, 
consults  the  appropriate  access  control  information,  and  then 
permits  or  denies  access  to  the  object  accordingly.  Any  reference 
to  an  object  must  be  validated  against  the  access  control 
information,  even  if  it  is  a  reference  by  another  program. 

The  mechanism  used  to  implement  the  reference  monitor  in  a 
system  must  meet  three  design  requirements:  isolation, 
completeness,  and  verif iability .  Isolation  means  the  mechanism 
must  be  tamper  proof.  To  achieve  completeness,  the  monitor  must  be 
used  for  every  access  decision  without  being  bypassed,  and  the 
monitor  must  be  capable  of  being  analyzed  and  tested  for 
verification. 

The  security  kernel  is  the  operating  system  mechanism  that  is 
normally  used  to  implement  the  reference  monitor  concept.  As  such, 
it  supervises  all  system  activity  in  accordance  with  the  system's 
security  policy.  In  following  with  the  design  principles  outlined 
above,  the  TCSEC  dictates  that  the  security  kernel  "must  mediate 
all  access,  be  protected  from  modification,  and  be  verifiable  as 
correct."  [Ref.  5]  The  security  kernel  is  typically  viewed  as  the 
heart  of  the  TCB .  (Note:  the  reference  monitor  concept  does  not 
apply  to  a  Class  C2  system.) 
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4.  Bell  and  LaPadula  Model 

Models  are  used  to  precisely  express  a  system's  security 
requirements.  All  mechanisms  used  to  support  the  security  policy 
must  conform  to  the  selected  model  for  the  system.  The  Bell  and 
LaPadula  model  was  the  first  mathematical  model  for  DOD  security 
policy  and  was  the  model  selected  for  use  with  the  TCSEC.  The 
model  provides  a  formal  description  of  the  paths  over  which 
information  is  allowed  to  flow  in  a  secure  system  and  applies 
strictly  to  the  secrecy  of  the  information.  The  paths  are 
important  since  they  describe  acceptable  relationships  between 
subjects  and  objects  at  different  levels  of  sensitivity.  The 
following  provides  the  details  of  the  model: 

Each  system  covers  a  set  of  subjects  S  and  a  set  of 
objects  0.  For  each  subject  s  in  S  and  each  object  o  in 
0  there  is  a  fixed  security  class  C(s)  and  C(o)  .  The 
security  classes  are  ordered  by  a  relation  <. 

Two  properties  characterize  the  secure  flow  of  information: 

Simple  Security  Property:  A  subject  s  may  have  read  access  to 
an  object  o  only  if  C(o)  <  C(s) . 

♦-Property:   A  subject  s  who  has  read  access  to  an  object  o 
may  have  write  access  to  an  object  p  only  if  C(o)  <  C(p)  . 
[Ref.  8:  pp.  249-250] 

5 .  Discretionary  and  Mandatory  Access  Control 

The  features  of  a  computer  system  which  enable  access  to  an 
object  to  be  restricted  are  referred  to  as  access  control 
mechanisms.  The  controls  may  be  implemented  through  hardware  or 
software  features,  operating  procedures,  or  management  procedures. 
If  access  is  restricted  based  upon  the  identity  of  the  user  or 
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group  of  users,  then  a  Discretionary  Access  Control  (DAC)  policy  is 
used.  Under  a  DAC  policy,  an  authorized  user  is  capable  of  passing 
permissions  to  another  user.  For  example,  one  user  can  share  a 
file  with  another  user  and  permit  him/her  to  modify  the  file. 

In  contrast,  Mandatory  Access  Control  (MAC)  provides  a 
stricter  policy  than  DAC.  Under  a  MAC  policy,  access  to  system 
objects  is  restricted  according  to  the  sensitivity  of  the 
information  contained  in  the  object  and  the  authorization  level  of 
the  subject  to  access  that  information.  The  sensitivity  of  the 
information  is  represented  by  a  security  level  associated  with  the 
object,  and  the  subject's  authorization  level  is  normally 
represented  by  a  clearance.  Under  a  strictly  MAC  policy,  users  are 
not  permitted  to  share  files  or  to  pass  permissions  to  other  users. 

Any  access  control  policy  is  either  mandatory  or 
discretionary.  The  policy  is  a  "MAC  policy  if,  and  only  if,  it  can 
be  represented  by  a  partially  ordered  set  of  access  classes,- 
otherwise,  it  is  discretionary."  [Ref .  9]  A  key  distinction 
between  the  two  forms  is  the  level  of  protection  provided  against 
malicious  software.  For  example,  a  Trojan  Horse  can  bypass  DAC 
controls,  but  cannot  bypass  the  controls  of  a  MAC  policy.  This  can 
be  demonstrated  through  mathematical  algorithms.  Specifically, 
with  a  DAC  policy,  an  algorithm  which  determines  whether  an 
arbitrary  protection  system  will  ever  result  in  unauthorized  access 
to  information  cannot  be  devised.  [Ref.  10]  However,  with  a  MAC 
policy,  it  is  possible  to  construct  a  lattice  of  access  classes  and 
mathematically  prove  that  access  control  is  always  enforced. 
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6 .    Protection  Mechanisms 

Mechanisms  are  functional  features  of  a  computer  system  which 
are  designed  to  enforce  the  security  policy  and  accountability 
objectives.  The  mechanisms  addressed  by  the  TCSEC  include: 
identification  and  authentication,  Discretionary  Access  Control 
(DAC) ,  object  reuse,  and  audit  capabilities.   [Ref.  7:  p.  22] 

Identification  and  authentication  is  normally  achieved  by 
asking  for  a  login  name  followed  by  a  prompt  for  some  sort  of 
"proof"  that  the  user  is  in  fact  the  person  to  which  the  login  name 
is  assigned.  The  login  name  achieves  the  identification  and  the 
"proof"  is  used  for  authentication.  Three  types  of  "proof"  are 
used  for  most  systems:  "(1)  something  the  user  knows  (e.g.,  a 
password);  (2)  something  the  user  has  (e.g.,  an  authentication 
device);  or  (3)  something  the  user  is  (e.g.,  a  retinal  scan)." 
[Ref.  7:  p.  23]  Most  products  on  the  Evaluated  Products  List  (EPL) 
use  the  login  name  and  password  combination  to  accomplish 
identification  and  authentication. 

The  DAC  mechanism  is  used  to  restrict  access  to  objects  based 
upon  the  identity  of  a  subject.  Access  Control  Lists  (ACLs) , 
protection  bits,  capabilities,  profiles,  and  passwords  are  the  main 
mechanisms  used  to  implement  DAC.  ACLs  are  associated  with  objects 
and  identify  subjects  with  authorized  access  as  well  as  the  type  of 
access  granted.  Protection  bits  identify  access  privileges 
through  a  bit  vector,  with  each  bit  representing  a  different  type 
of  access  (e.g.,  read,  write,  etc.) .  The  protection  bits  may  be 
assigned  according  to  specific  categories  of  users  (e.g.,  owner, 
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group,  public)  to  implicitly  associate  access  rights  with 
individual  users.  Capabilities  may  be  assigned  to  a  user  for 
protected  objects  with  access  being  granted  to  a  subject  only  if  he 
or  she  has  the  appropriate  capability.  Profiles  associate  a 
listing  of  protected  objects  to  each  user  which  identifies  the 
objects  to  which  the  subject  has  been  granted  access.  Finally, 
passwords  may  be  used  to  permit  full  (all  types)  or  partial 
(different  types  such  as  read  only)  access  to  objects. 

Despite  the  specific  mechanism  used  to  implement  DAC  within  a 
computer  system,  all  DAC  implementations  are  susceptible  to  attack 
by  a  Trojan  Horse.  Specifically,  when  a  DAC  program  executes,  it 
uses  the  access  privileges  of  the  user  initiating  the  program.  A 
Trojan  Horse  will  utilize  these  permissions  to  pass  or  modify 
information  in  a  manner  not  intended  by  the  user.  If  separating 
classified  information  is  left  to  the  user's  discretion,  then  a 
Trojan  Horse  can  result  in  an  unauthorized  disclosure  of 
information.  Therefore,  DAC  mechanisms  are  not  sufficient  for 
segregating  objects  with  different  classification  levels.  A  Guide 
to  Understanding  Discretionary  Access  Control  in  Trusted  Systems 
provides  a  more  detailed  description  of  the  Trojan  Horse  problem. 
[Ref.  11:  pp.  5-6] 

Object  reuse  provides  assurance  that  information  is  not 
available  to  other  users  once  storage  space  has  been  reallocated. 
Table  1  was  taken  from  NCSC's  Assessing  Controlled  Access 
Protection  document  and  outlines  the  various  object  reuse 
mechanisms  for  the  various  types  of  storage  objects. 
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The  audit  criterion  requires  that  the  computer  system  be 
capable  of  collecting  information  regarding  system  events.  The 
audit  features  provide  a  record  of  security  related  events  which 
may  be  examined  either  as  the  events  are  occurring  or 
retrospectively.  Once  the  audit  mechanism  collects  the  event  data, 


Storage  Object 

Imp 1 ementa t i on 

Primary  Storage 

(e.g.,  random  access  memory, 

cache,  translation  buffer) 

-  Overwriting  memory  page  with 

fixed  or  random  pattern 
and/or  (for  efficiency)  new 
data 

Fixed  Media 

(e.g.,  fixed  disk,  terminal, 

operator  console) 

-  Overwriting  physical  data 
blocks 

-  Purging  associated  entries 
in  page  management  table 

-  Purging  directory 
information  residing  on 

media 

Removable  Media 

-  On-line  overwriting  with 
approved  fixed  or  random 
pattern 

-  Degaussing 

-  Off-line  overwriting 

Table  1.  Object  Reuse  Mechanisms  [Ref  7] 
the  TCB  must  protect  it  from  unauthorized  modification  or 
destruction.  At  a  minimum,  the  audit  mechanism  must  be  able  to 
record  the  following  types  of  events:   [Ref  7:  p.  31] 


•  System  logins 

•  Introduction  of  objects  into  a  user's  address  space  (e.g., 
file  open,  file  creation,  program  execution,  file  copy) 

•  Deletion  of  objects  from  a  user's  address  space  (e.g.,  file 
close,  completion  of  program  execution,  file  deletion) 

•  Actions   taken  by   system  administrators   and/or   system 
security  personnel  (e.g.,  adding  a  user) 
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•  All  security  relevant  events   (e.g.,  use  of  privileges, 
changes  to  DAC  parameters) 

•  Print  requests 

In  addition  to  the  type  of  event  recorded,  the  audit  mechanism 
must  identify  the  time  and  date  of  the  event,  the  origin  of  the 
request,  whether  it  was  a  success  or  failure,  and  provide  a  unique 
identifier  representing  the  subject  who  requested  or  "supposedly" 
requested  the  event.  If  the  event  is  the  introduction  or  deletion 
of  an  object  to  a  user's  address  space,  then  the  name  of  the  object 
must  be  recorded.  Finally,  any  actions  taken  by  the  system 
administrator  must  be  described  in  the  audit  trail . 

D.    PRODUCT  EVALUATION 

The  National  Computer  Security  Center  (NCSC)  evaluates 
operating  systems  and  other  products  according  to  the  criterion  set 
forth  in  the  TCSEC  through  the  Trusted  Product  Evaluation  Program 
(TPEP)  .  TPEP  is  the  primary  program  of  the  NCSC  and  is  aimed 
specifically  at  Commercial  Of f -The-Shelf  (COTS)  products  which  meet 
the  needs  of  the  government.  To  be  certified  at  a  specific  level 
of  trust,  the  product  and  vendor  must  complete  both  a  preliminary 
product  evaluation  and  a  formal  product  evaluation.  Once  a  product 
is  assigned  a  specific  rating,  it  is  placed  on  the  Evaluated 
Products  List  with  its  assigned  rating.  The  Rating  Maintenance 
Program  (RAMP)  allows  for  technological  advancements,  by  permitting 
software  changes  and  new  hardware  platforms  to  be  added  to  the 
evaluated  package. 
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It  is  important  to  remember  that  although  a  system  is  assigned 
a  specific  rating,  that  rating  pertains  only  to  the  hardware 
platform  on  which  the  testing  was  completed.  Therefore,  if  an 
operating  system  was  assigned  a  Class  C2  rating  on  a  Compaq 
Proliant  2000  without  floppy  drives,  the  Class  C2  rating  would  not 
be  transferrable  to  a  different  platform  such  as  a  Gateway  2000  P5- 
120  with  floppy  drives.  In  addition,  products  evaluated  according 
to  the  TCSEC  do  not  maintain  that  rating  when  used  in  a  networked 
environment.  The  TCSEC  focuses  strictly  on  stand-alone  systems 
which  are  not  interconnected  with  other  systems. 

As  the  number  of  computer  networks  continues  to  grow,  the  need 
for  products  evaluated  for  a  networked  environment  is  rapidly 
increasing.  Evaluations  for  networked  products  follow  an  expanded 
testing  process  based  upon  the  Trusted  Network  Interpretation  (TNI) 
or  Red  Book.  (The  TNI  will  be  discussed  in  further  detail  in  the 
next  chapter.)  The  evaluation  process  used  to  assess  the  security 
characteristics  of  a  product  in  a  networked  environment  is  referred 
to  as  the  TPEP  Network  Evaluation. 

Although  the  analysis  performed  by  the  TPEP  or  TPEP  Network 
Evaluation  provides  valuable  information  for  the  security  of  a 
system,  it  does  not  replace  the  need  for  system  approval  and 
accreditation.  Every  environment  is  unique  and  must  be  analyzed 
for  the  overall  security  of  the  system  and  the  data  to  be  processed 
by  the  system.  The  accreditation  process  provides  an  avenue  for 
this  unique  evaluation  to  be  conducted. 
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E.    CERTIFICATION  AND  ACCREDITATION 

Certification  and  accreditation  are  the  terms  used  to  describe 
the  process  of  analyzing  a  computer  system  to  determine  the  level 
of  security  afforded  based  upon  a  defined  security  policy  and  a  set 
of  security  features.  Specifically,  certification  refers  to  the 
technical  evaluation  of  a  system  and  accreditation  is  the  formal 
declaration  that  a  system  is  approved  to  operate  in  a  specific 
security  mode  for  a  specified  period  of  time. 

Accreditation  assigns  responsibility  for  the  operation  of  the 
system  to  the  Designated  Approving  Authority  (DAA) .  Some  types  of 
systems  may  actually  require  more  than  one  DAA,  depending  on  the 
environment  and  the  amount  of  interface  with  other  systems .  For 
example,  a  system  that  is  connected  to  a  backbone  network  or  a 
system  that  supports  multiple  organizations  will  require  more  than 
one  DAA. 

Prior  to  allowing  any  computer  system  to  process  or  store 
classified  or  sensitive  information,  the  DAA  must  complete  the 
certification  and  accreditation  process  for  the  system  to  operate 
in  one  of  three  security  modes : 

•  Dedicated  Mode:  All  users  have  the  appropriate  clearance 
and  need-to-know  for  all  of  the  data  processed  by  the 
computer  system. 

•  System  High:  All  users  have  the  proper  security  clearance, 
but  may  not  have  a  need-to-know  for  all  of  the  data 
processed  by  the  computer  system. 

•  Mul t i 1 eve 1  Mode :  Permits  two  or  more  classification  levels 
of  data  to  be  processed  simultaneously  within  the  computer 
system.  Not  all  of  the  users  have  the  appropriate  clearance 
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or  access  approval  for  all  of  the  data  maintained  by  the 
system. 

NCSC  standard  003-85,  Guidance  for  Applying  the  Department  of 
Defense  Trusted  Computer  System  Evaluation  Criteria  in  Specific 
Environments  [Ref .  12],  provides  the  government's  policy  for 
computer  systems  which  handle  classified,  sensitive,  and 
unclassified  information,  as  well  as  details  regarding  the 
selection  of  the  appropriate  level  of  trust  for  any  environment. 
The  level  of  trust  is  determined  by  computing  the  system' s  risk 
index  which  is  defined  as  "the  disparity  between  the  minimum 
clearance  or  authorization  of  system  users  and  the  maximum 
sensitivity  of  data  processed  by  a  system."  [Ref.  12:  p.  5]  The 
risk  index  is  then  used  in  conjunction  with  a  table  to  determine 
the  appropriate  level  of  trust  for  the  system' s  environment . 

The  certification  process  is  the  set  of  procedures  used  to 
determine  if  a  system  meets  the  specific  security  requirements  for 
the  operational  environment.  If  all  requirements  are  met,  the 
system  will  then  be  accredited  by  the  DAA  as  meeting  the  required 
level  of  trust.  The  certification  and  accreditation  process  is 
needed  to  ensure  system  users  and  administrators  are  able  to  "trust 
the  system's  ability  to  accurately,  consistently,  and  positively 
identify  each  user,  and  to  maintain  that  positive  identification 
throughout  the  user's  login  session.  Otherwise,  controlled  access 
protection  could  not  be  assured,  and  any  audit  information 
collected  would  be  rendered  useless."  [Ref.  7:  p.  22]  Specific 
details  regarding  who  should  conduct  the  certification,  the  steps 
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involved  in  the  process,  and  risk  management  are  provided  in  the 
following  sections. 

1.  System  Analysts 

NCSC  recommends  the  actual  system  analysis  be  performed  by  a 
team  of  individuals  to  ensure  the  required  levels  of  controlled 
access  protection  are  provided.  All  members  of  the  team  should 
have  the  equivalent  of  at  least  a  bachelor's  degree  in  Computer 
Science  or  Computer  Engineering.  In  addition,  at  least  one  member 
should  have  expertise  in  the  hardware  architectures  and  all  members 
should  have  a  strong  knowledge  of  the  operating  systems  and  a 
thorough  understanding  of  computer  security  issues.  Prior  to 
analyzing  the  system,  the  team  should  be  fully  educated  on  the 
system's  mission,  environment,  security  policy,  and  any  identified 
threats.  [Ref .  7:  p.  41] 

2 .  Technical  Analysis 

The  certification  and  accreditation  of  a  system  is  performed 
through  a  series  of  interdependent  steps.  NCSC's  Introduction  to 
Certification  and  Accreditation  [Ref.  13]  manual  provides  a 
detailed  description  of  these  steps  which  are  briefly  described 
below. 


•  Step  1.  Assess  System  Requirements /Assess  Tailoring 
Factors:  The  focus  of  this  step  is  to  identify  and  assess 
the  aspects  of  the  system  which  are  relevant  to  security. 
This  includes  functional  requirements,  security  policies, 
threat  information,  mission  requirements,  security 
boundaries,  and  other  pertinent  data. 

•  Step  2.  Plan  for  Certification  &  Accreditation:  System 
milestones  and  resource  requirements  such  as  personnel 
training  and  equipment  purchases  should  be  identified. 
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Information  to  conduct  the  actual  system  analysis  is 
incorporated  into  system  documentation. 

•  Step  3.  Perform  System  Analysis:  The  system  security 
attributes  as  a  whole  are  analyzed.  Security  measures  are 
assessed  and  tested  with  system  vulnerabilities  and  risks 
identified. 

•  Step  4.  Report  Findings /Recommendations :  The  results  and 
recommendations  of  the  previous  phases  are  documented  and  a 
certification/accreditation  package  is  developed.  The 
package  provides  the  DAA  with  a  recommendation  for  an 
accreditation  decision,  a  statement  of  residual  risk  and 
supporting  documentation. 

•  Step  5.  Conduct  Site  Survey:  An  optional  step,  a  site 
survey  is  conducted  by  the  DAA  or  his/her  representative  to 
ensure  the  security  countermeasures  meet  the  system 
requirements . 

•  Step  6.  Make  Accreditation  Decision:  The  DAA  makes  the 
accreditation  decision  using  one  of  the  following  options: 
full  accreditation  for  the  originally  intended  environment, 
partial  accreditation  for  operation  outside  the  originally 
intended  environment,  interim  accreditation  approval,  or 
accreditation  disapproval.  If  multiple  DAAs  are  involved, 
a  Memorandum  of  Agreement  (MOA)  must  be  developed  and  signed 
as  part  of  the  accreditation  decision. 

•  Step  7.  Maintain  Accreditation:  Accreditation  must  be 
maintained  throughout  the  system's  life  cycle  by  ensuring 
operation  continues  within  the  stated  parameters  of 
accreditation.  Current  DOD  policy  requires  a  system  to  be 
reaccredited  every  three  years,  regardless  of  any  changes 
that  may  or  may  not  have  occurred. 

Figure  2  provides  a  graphical  depiction  of  the  overall 
certification  and  accreditation  process.  In  addition  to  these 
steps,  the  actual  system  analysis  (step  3)  may  be  further  broken 
down  into  a  separate  set  of  steps.  Assessing  Controlled  Access 
Protection  [Ref .  7]  describes  each  of  these  steps  in  detail  and 
provides  a  graphical  depiction  of  the  entire  process. 
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Pre-certification  Phase 


Step  1 
Assess  System  Requirements/ 
Assess  Tailoring  Factors 


Step  2 
Plan  for  C  &  A 


Certification   Phase 


Step  3 
Perform  System  Analysis 


Step  4 
Report  Findings/ 
Recommendations 


Accreditation  Phase 


Step  5 
Conduct  Site  Survey 


Step  6 
Make  Accreditation 
Decision 


Post -Accreditation   Phase 


Step  7 
Maintain 
Accreditation 


Figure  2 .   Certification  and  Accreditation  Process 

[Ref.  13:  p.  8] 
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3 .    Risk  Management 

"Because  absolute  security  is  neither  technically  nor 
theoretically  attainable  in  a  multi-user  system,  determining 
whether  a  system  is  'secure'  is  essentially  an  exercise  in 
identifying  risks  and  counterbalancing  those  risks  against 
protection  mechanisms.  Therefore,  the  ultimate  objective  of  any 
security  program  is  risk  management."  [Ref.  7:  p.  53]  Risk 
management  encompasses  the  total  process  of  identifying,  measuring, 
and  minimizing  uncertain  events  which  can  affect  the  computer 
system. 

Risk  management  begins  with  a  risk  analysis  of  the  computer 
system  which  evaluates  the  relative  costs  and  benefits  of  security 
measures  and  identifies  those  measures  which  are  acceptable  to 
reduce  the  level  of  risks  to  the  system.  The  term  risk  is  used  to 
identify  a  measure  of  the  potential  loss  to  a  computer  system  from 
a  threat  and  the  system's  vulnerability  to  that  threat.  Risk 
analysis  is  an  on-going  process  which  occurs  throughout  a  system' s 
life  cycle.  As  such,  it  is  a  tool  used  by  the  DAA  to  ensure  the 
system's  security  policy  is  being  enforced  at  an  appropriate  level 
relative  to  the  assumed  risks.  Once  a  system  is  accredited,  the 
need  for  risk  analysis /management  does  not  end,  rather  it  begins. 

There  are  numerous  checklists  available  which  may  be  used  to 
assist  with  risk  management.  For  example,  the  book  Computer 
Security:  A  Comprehensive  Controls  Checklist  [Ref.  14]  provides  a 
very  thorough  checklist  for  assessing  the  threats  to  a  computer 
system.   The  checklist  was  designed  for  an  Air  Force  installation 
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and  "provides  a  number  of  controls  for  each  major  type  of  threat 
against  an  information  system."  [Ref .  14:  p.  11]  The  controls  are 
presented  in  list  form  with  provisions  for  three  possible  answers: 
yes,  no,  and  not  applicable.  For  a  control  to  be  applicable,  the 
threat  must  exist  and  an  asset  must  need  protection.  If  the  control 
is  applicable,  then  a  "yes"  or  "no"  is  checked  to  represent  that 
the  control  does  or  does  not  exist  within  the  system.  The  book  also 
describes  how  to  assign  weights  to  the  various  requirements  so 
priorities  may  be  assigned.  The  areas  addressed  by  the  various 
checklists  include:  personnel  policies,  system  development, 
training/awareness,  organization  structure,  physical  access,  data 
and  program  access,  input /output,  processing  operations,  database 
and  system  software,  telecommunications,  and  video  display  terminal 
human  factors . 
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IV.   THE  TRUSTED  NETWORK  INTERPRETATION 

Many  of  the  mechanisms  defined  by  the  TCSEC  are  applicable  to 
networked  environments  as  well.  However,  the  TCSEC  provides  no 
guidance  for  its  application  to  networks.  In  addition,  the  TCSEC 
is  void  in  two  major  areas  where  networks  are  concerned.  First, 
while  the  TCSEC  addresses  single-system  security,  networks 
typically  involve  many  systems  with  different  architectures  and 
different  security  vulnerabilities.  In  today's  environment  of 
piecemeal  systems  being  interconnected  to  form  a  network,  an 
evaluation  criterion  which  helps  to  ensure  a  secure  network  without 
requiring  every  component  of  the  network  to  be  fully  trusted  is 
needed.  By  providing  explicit  design  criterion  for  networks, 
system  designers  will  be  forced  to  think  about  the  placement  of 
trust  within  the  overall  network.  Second,  the  TCSEC  primarily 
addresses  the  computer  security  goals  of  secrecy  and  integrity  by 
focusing  on  access  to  information  written  on  a  computer  system.  Two 
additional  goals,  availability  and  authenticity,  are  extremely 
important  in  networked  environments.  Because  of  these  voids  and 
due  to  concerns  regarding  the  transmission  of  government  data  over 
communication  networks,  a  standard  format  to  be  used  with  the 
evaluation  of  computer  networks  was  needed. 

Building  upon  the  criterion  set  forth  in  the  TCSEC,  the  NCSC 
published  the  Trusted  Network  Interpretation  (TNI)  of  the  Trusted 
Computer  System  Evaluation  Criteria  [Ref .  15]  or  "Red  Book"  in 
1987.  The  TNI  is  part  of  the  Rainbow  Series  and  was  developed  to 
provide  further  guidance  for  networks  and  network  components .   The 
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criterion  of  the  TNI  may  be  used  to  cover  the  range  of  networks 
from  isolated  local  area  networks  to  wide  area  internetworks. 

The  TNI  is  divided  into  two  major  sections.  Part  I  breaks 
down  each  of  the  divisions  and  classes  described  in  the  TCSEC  and 
provides  an  interpretation  of  the  requirements  for  a  networked 
environment.  The  same  divisions  and  classes  of  trust  are  used 
(i.e.,  D,  CI,  C2,  Bl,  etc.).  Since  networks  require  additional 
security  services  (e.g.,  availability,  communications  security), 
Part  II  of  the  TNI  describes  specific  services  which  may  or  may  not 
be  required  in  a  network  and  furnishes  a  method  for  assessing  those 
services.  The  security  services  included  are  communications 
security,  denial  of  service,  transmission  security,  and  supportive 
services  (e.g.,  encryption  tools  and  network  management) . 

Part  II  of  the  TNI  also  describes  how  the  different  components 
of  a  network  may  be  categorized  according  to  the  type  of  mechanism 
provided.  The  four  categories  are  Mandatory  Access  Control  (MAC) , 
Discretionary  Access  Control  (DAC) ,  Audit,  and  Identification  and 
Authentication.  The  TNI  abbreviates  these  categories  as  M,  D,  A, 
and  I,  respectively.  A  network  component  may  be  functionally  used 
for  any  combination  of  these  categories.  Therefore,  a  total  of  16 
component  types  (including  no  features  provided)  may  be  used  in  a 
network.  Each  component  is  rated  according  to  the  corresponding 
TCSEC  functional  requirements  for  that  category.  The  C2+  rating  is 
used  to  denote  that  a  component  meets  the  Class  B3  DAC  and  audit 
functional  requirements,  but  does  not  provide  any  MAC  features. 
Through  this  rating  structure,   components  may  be  combined  to 
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provide  an  aggregate  level  of  trust.  For  example,  a  "D"  component 
which  is  rated  as  C2+  may  be  combined  with  other  components  which 
are  given  a  Class  B3  or  Al  rating  to  produce  a  Class  B3  or  Al 
system.  [Ref .  16]  (This  would  only  work  if  the  "D"  component  were 
given  a  Class  C2+  rating.  A  Class  C2  component  could  not  be 
combined  in  this  manner.) 

The  TNI  assigns  a  minimum  and  maximum  rating  for  each 
component  type.  Table  2  provides  a  listing  of  the  possible 
component  types  and  the  corresponding  rating  range. 


Component  Type 

Minimum  Class 

Maximum  Class 

M 

Bl 

Al 

D 

CI 

C2  + 

I 

CI 

C2 

A 

C2 

C2  + 

DI 

CI 

C2  + 

DA 

C2 

C2  + 

IA 

C2 

C2  + 

IAD 

C2 

C2  + 

MD 

Bl 

Al 

MA 

Bl 

Al 

MI 

Bl 

Al 

MDA 

Bl 

Al 

MDI 

Bl 

Al 

MIA 

Bl 

Al 

MIAD 

Bl 

Al 

A. 


Table  2 .  Component  Types  and  Corresponding  Rating  Classes 

[Ref.  15:  p.  196] 

PART  II  SECURITY  SERVICES 


The  security  services  described  in  Part  II  of  the  TNI  are 
rated  according  to  their  functionality,  strength  of  mechanism,  and 
level  of  assurance.  Functionality  refers  to  the  objective  the 
security  service  is  to  fulfill  and  the  approach  used  to  meet  that 
objective.     The   features  provided  by   the   service   and   its 
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performance  are  included  under  the  heading  of  functionality.  The 
strength  of  the  mechanism  measures  how  effectively  the  service 
meets  its  objective.  Both  direct  and  indirect  threats  to  the 
network  must  be  considered  in  determining  the  strength  of  the 
mechanism.  Finally,  assurance  refers  to  the  level  of  trust  the 
users  may  place  on  the  service  that  it  will  achieve  the  desired 
functionality.  Tamper  resistance,  verif iability,  and  the  inability 
to  bypass  the  service  are  three  aspects  which  must  be  considered  in 
rating  the  level  of  assurance. 

Evaluation  of  the  services  provided  in  a  network  is 
qualitative  and  results  in  a  rating  of  none,  minimum,  fair,  or 
good.  In  some  cases,  the  functionality  of  a  service  may  be 
described  as  either  none  or  present,  if  rating  the  degree  of 
functionality  may  not  be  appropriate.  The  term  none  is  normally 
used  to  describe  if  the  service  does  not  support  the  strength  of 
the  mechanism  criterion.  Finally,  if  a  security  service  is  not 
offered,  then  the  term  not  present  is  used  as  the  rating.  Table  3 
was  taken  from  the  Trusted  Networks  Interpretation  Environments 
Guideline  [Ref .  17]  and  provides  a  breakdown  of  the  security 
services  and  the  range  of  ratings  that  may  be  used  for  each 
criterion. 

The  security  services  addressed  are  not  required  by  every 
network.  Similarly,  the  strength  of  the  service  required  will  vary 
from  network  to  network  according  to  the  operational  environment  in 
which  it  is  used.  Selecting  the  appropriate  security  services  for 
a  network  is  a  management  decision.    The  Trusted     Networks 
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Interpretation  Environments  Guideline  [Ref.  17]  provides  a  series 
of  questions  the  manager  may  use  to  determine  the  services  that  are 
needed  and  the  functionality  required.  Once  it  has  been  determined 
that  a  service  is  required  and  the  functionality  has  been 
identified,  the  strength  of  the  mechanism  and  the  level  of 
assurance  is  determined  through  a  risk  index  which  is  also  provided 
in  the  TNI  guideline. 


Network  Security  Service 

Criterion 

Evaluation  Range 

Communications  Integrity/ 
Authentication 

Functionality 

Strength 

Assurance 

None,  Present 
None  -  Good 
None  -  Good 

Communications  Field 
Integrity 

Functionality 

Strength 

Assurance 

None  -  Good 
None  -  Good 
None  -  Good 

Non-Repudiation 

Functionality 

Strength 

Assurance 

None,  Present 
None  -  Good 
None  -  Good 

Denial  of  Service/ 
Continuity  of  Operations 

Functionality 

Strength 

Assurance 

None  -  Good 
None  -  Good 
None  -  Good 

Protocol  Based  Protection 

Functionality 

Strength 

Assurance 

None  -  Good 
None  -  Good 
None  -  Good 

Network  Management 

Functionality 

Strength 

Assurance 

None,  Present 
None  -  Good 
None   Good 

Compromise  Protection/ 
Data  Confidentiality 

Functionality 

Strength 

Assurance 

None,  Present 
Sensitivity  Level 
None   Good 

Traffic  Flow 
Confidentiality 

Functionality 

Strength 

Assurance 

None,  Present 
Sensitivity  Level 
None  -  Good 

Selective  Routing 

Functionality 

Strength 

Assurance 

None,  Present 
None  -  Good 
None  -  Good 

Table  3 .   Evaluation  Structure  for  Network  Security  Services 

[Ref.  17:  p.  27] 
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B.    ENSURING  TRUST 

Any  network  evaluated  using  the  TNI  must  have  a  rational 
Network  Security  Architecture  and  Design  (NSAD)  which  addresses  the 
security  relevant  policies,  objectives,  and  protocols.  The 
interfaces  and  services  which  are  needed  for  the  network  to  be 
evaluated  as  a  trusted  system  must  be  specified  as  well  as  the 
security  functionality  of  the  various  components. 

Just  like  a  stand-alone  system,  the  network  also  maintains  a 
Trusted  Computing  Base  (TCB)  which  is  referred  to  as  the  Network 
TCB  (NTCB)  .  The  NTCB  includes  all  of  the  security- relevant 
components  of  the  network.  In  contrast  to  the  "stand-alone  system, 
the  design  and  evaluation  of  the  network  rests  on  an  understanding 
of  how  the  security  mechanisms  are  distributed  and  allocated  to 
various  components,  in  such  a  way  that  the  security  policy  is 
supported  reliably  in  spite  of  (1)  the  vulnerability  of  the 
communication  paths  and  (2)  the  concurrent,  asynchronous  operation 
of  the  network  components."  [Ref .  15:  p.  xvii]  When  a  NTCB  is 
distributed  over  several  network  components,  the  portion  of  the 
NTCB  within  a  given  component  is  referred  to  as  an  NTCB  partition. 

For  a  network  to  be  evaluated  at  a  specific  class,  the  network 
as  a  whole  must  meet  every  requirement  for  that  class  as  outlined 
in  Part  I  of  the  TNI .  This  does  not  mean  that  every  network 
component  must  satisfy  all  of  the  requirements.  For  example,  one 
component  may  rely  on  another  component  to  meet  a  specific 
requirement.  Neither  component  will  satisfy  the  requirement 
individually,  but  together  the  requirement  is  met  for  the  network. 

52 


C.    CERTIFICATION  AND  ACCREDITATION 

Products  are  submitted  to  the  NCSC  for  evaluation  in  a  network 
environment  using  the  TNI  criterion  the  same  way  stand-alone 
systems  are  evaluated  using  the  TCSEC .  However,  since  there  are 
additional  security  concerns  with  a  network  environment,  additional 
testing  is  required.  Although  a  product  completes  the  formal 
evaluation  process  conducted  by  the  NCSC  and  may  be  certified  to 
run  at  a  specific  level  (e.g.,  Class  C2)  ,  the  NCSC  evaluation 
process  does  not  eliminate  the  need  for  system  certification  and 
accreditation.  As  described  in  the  previous  chapter,  a  network 
must  be  evaluated  and  accredited  for  operation  in  its  specific 
environment  the  same  as  a  stand-alone  computer.  However,  if  the 
network  uses  a  commercial  product  that  has  been  evaluated  and 
certified  by  the  NCSC,  reports  from  that  process  may  be  used  as 
input  to  the  systems  certification. 

There  are  two  distinct  views  which  may  be  used  to  certify  and 
accredit  a  network.  It  may  be  viewed  as  a  collection  of  two  or 
more  interconnected  separately  accredited  computer  systems,  or  it 
may  be  accredited  as  one  large  system.  The  view  which  is  selected 
will  have  a  major  impact  on  the  security  features  required  and  the 
level  of  assurance  of  the  system.  Therefore,  the  desired  approach 
must  be  defined  prior  to  the  start  of  the  certification  process. 

1.    Interconnected  Accredited  System  View 

This  view  recognizes  that  parts  of  a  network  may  be 
independently  created,  managed,  and  accredited.  The  interconnected 
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system  consists  of  multiple  systems  which  may  be  viewed  as  devices 
or  components  to  which  the  other  systems  may  transfer  information. 
Each  individual  system  or  "device"  must  be  assigned  a  sensitivity 
level  for  the  information  it  processes. 

When  evaluating  an  interconnected  accredited  system,  two 
additional  security  problems  must  be  considered:  propagation  of 
local  risk  and  the  cascade  problem.  Propagation  of  local  risk 
refers  to  the  security  of  one  system  being  endangered  by  a  weakness 
in  another  system  which  is  connected  to  it.  Since  the  overall 
system  may  have  several  accreditors,  one  must  remember  that  a  risk 
which  is  acceptable  to  one  person  may  not  be  acceptable  to  another. 
Special  constraints  such  as  one-way  connections,  cryptographic 
isolation,  or  other  measures  may  be  imposed  on  a  system  to  help 
limit  the  amount  of  risk  introduced  to  the  overall  system. 

The  cascade  problem  exists  when  subsystems  are  connected  in  a 
manner  which  results  in  the  overall  system  covering  a  larger 
sensitivity  range  than  the  individual  systems  are  accredited  to 
handle.  In  this  case,  an  attacker  may  be  able  to  exploit  the 
network  connections  in  order  to  leak  information  across  the  range 
of  sensitivity  levels.  This  depends  on  the  cooperation  by 
malicious  software  between  the  various  subsystems.  Several 
approaches  may  be  taken  to  prevent  this  problem  from  occurring. 

•  Configuration  controls  may  prohibit  the  introduction  of  new 
software  or  software  which  has  not  been  appropriately 
examined . 

•  Increasing  the  trust  requirements  for  the  various  subsystems 
may  increase  the  protection  mechanisms  to  a  level  that  is 
appropriate  for  the  potential  compromise. 
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•  Some  network  connections  may  need  to  be  eliminated  from  the 
overall  system. 

Both  the  TNI  and  the  Trusted  Network  Interpretation  Environments 
Guideline  discuss  the  propagation  of  local  risk  and  the  cascade 
problem  in  greater  detail.  In  addition,  information  is  provided  on 
how  the  problems  may  be  identified  if  they  exist  in  a  network  and 
how  they  may  be  solved. 

Finally,  adopting  the  Interconnected  Accredited  System  view 
may  result  in  a  very  complex  system  which  cannot  be  practically 
evaluated  using  the  TNI  criterion.  In  that  case,  the  system 
"accreditor  is  forced  to  accept  the  risk  of  assessing  the  security 
of  the  network  without  the  benefit  of  an  evaluation  against  the 
principles  of  the  TCSEC."   [Ref.  15:  p.  xiii] 

2.    Single  Trusted  System  View 

This  view  treats  the  overall  network  as  a  single  trusted 
system  which  is  accredited  by  one  authority.  "The  single  trusted 
system  implements  a  reference  monitor  to  enforce  the  accesses  of 
subjects  to  objects  in  accordance  with  an  explicit  and  well  defined 
network  security  policy."  [Ref.  15:  p.  xiv]  In  addition,  the  NTCB 
is  partitioned  among  the  various  network  components  which  interact 
through  the  communication  channels.  The  NTCB  partitions  must  be 
implemented  so  the  network  security  policy  is  enforced  for  the 
network  as  a  whole.  This  approach  is  normally  not  as  complex  as 
the  interconnected  system  approach  and  may  result  in  a  more  secure 
level  of  trust  in  a  system. 


55 


56 


V.   THE  FALCON  LAN  -  APPLYING  THE  TCSEC/TNI  CRITERION 

The  Naval  Security  Group  Detachment  (NSGD)  Monterey  is  the 
Naval  contingent  of  the  Defense  Language  Institute  (DLI) .  As  such, 
NSGD  is  responsible  for  the  training  and  well  being  of  the  Navy- 
students  at  DLI.  During  the  fall  of  1995,  NSGD  installed  the 
Falcon  Local  Area  Network  (LAN)  to  assist  with  their  charter  to 
provide  administrative,  educational,  and  communication  support  for 
both  students  and  staff  personnel.  The  majority  of  the  hardware  and 
software  purchased  for  the  LAN  was  provided  by  NSGD's  headquarters, 
Commander  Naval  Security  Group  (CNSG) ,  and  the  backbone 
installation  was  performed  by  NISE  WEST. 

A.    SYSTEM  FUNCTIONALITY  AND  GOALS 

The  NSGD  staff  has  defined  the  following  functional 
requirements  for  the  Falcon  LAN.  Since  the  initial  installation  of 
the  LAN,  not  all  of  the  requirements  have  been  met.  Those  which 
have  not  been  met  are  scheduled  for  future  implementation. 

•  Provide  a  Communications  System:  The  LAN  provided  a 
backbone  communication  system  for  the  various  NSGD  offices 
located  in  two  different  buildings.  Specifically,  the  LAN 
joined  the  Learning  Center  and  administration  offices  in 
building  629  with  the  Commander's  office  and  yeoman  offices 
in  building  616  using  a  client-server  structure. 

•  Provide  a  Student  Tracking  System:  The  LAN  included  the 
development  of  a  unified  database  for  tracking  student 
information  including  student  course  assignment  and 
completion,  barracks  room  assignments,  security  clearance 
information,  past  performance  information  and  other 
information  relating  to  the  individual  student . 
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•  Provide  for  Service  Management:  Access  was  needed  to  the 
DLI  student  database,  Navy  Integrated  Training  Requirements 
and  Resources  System  (NITRAS) ,  and  the  Army  Training 
Requirements  and  Resources  System  (ATRRS)  programs  to  allow 
for  the  assignment  of  students  to  language  curriculums  to 
meet  service  needs  and  student  eligibility  requirements. 

•  Provide  for  Supply  and  Fiscal  Tracking:  Access  was  also 
required  to  the  Naval  Postgraduate  School  supply  system,  the 
new  supply  and  purchasing  system,  and  on-line  catalogs  and 
supply  status  servers . 

•  Provide  Career  Counseling  Assistance:  A  provision  for  the 
maintenance  and  access  to  the  student  database  with  career 
counseling  information  such  as  Armed  Services  Vocational 
Aptitude  Battery  (ASVAB)  scores,  next  duty  assignment,  and 
prospective  gains  and  losses  was  also  needed.  In  addition, 
the  LAN  was  to  provide  the  Educational  Services  Officer  with 
course  completion,  Personnel  Advancement  Requirements  (PARS) 
and  other  advancement  information  and  provide  personnel  with 
access  to  the  Bureau  of  Naval  Personnel  (BUPERS)  bulletin 
board  and  detailer  electronic  mail. 

•  Provide  for  Command  Information  Dissemination :  The  LAN  was 
to  provide  a  route  for  the  dissemination  and  tracking  of 
command  welcome  aboard  packages,  provide  NSGD  personnel  with 
access  to  the  World  Wide  Web  (WWW)  server,  and  provide 
outside  access  to  the  Defense  Language  Institute  NSGD  home 
page. 

•  Allow  for  the  sharing  of  electronic  mail  with  DLI:  Access 
to  and  compatibility  with  the  DLI  Microsoft  Mail  server  was 
needed  to  allow  the  transfer  of  electronic  mail  between  the 
staffs.  In  conjunction  with  this,  all  NSGD  Staff  and  Navy 
and  Marine  students  needed  electronic  mail  accounts  to  allow 
for  the  free  exchange  of  electronic  mail  within  the  command 
and  with  other  DLI  electronic  mail  users. 

•  Provide  for  the  Instruction  of  the  Cryptologic  Technician 
Apprentice  Common  Core  Curriculum  using  the  LAN:  To 
complete  the  automation  of  all  NSGD  requirements  and  provide 
total  connectivity,  connections  with  the  Educational  LAN  in 
the  Learning  Center  were  needed.  This  would  allow  for 
interactive  CD-ROM  instruction  of  the  Cryptologic  Technician 
Apprentice  Common  Core  Curriculum  and  provide  a  CD-ROM 
library  for  access  by  the  LAN. 

In  addition  to  the  functional  requirements  specified  above, 

one  additional  function  was  desired  for  the  LAN  -  to  provide  the 

ability  to  receive  unclassified  message  traffic  using  the  Defense 
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Message  System  (DMS) .  Currently,  all  message  traffic  (classified 
and  unclassified)  is  received  on  a  stand-alone  personal  computer 
running  an  awkward  program  called  Above  Board.  Unclassified 
message  traffic  is  screened  and  then  distributed  on  the  LAN  using 
a  CNSG-approved  program  called  Message  Board.  The  actual  progress 
made  to  date  in  achieving  these  requirements  will  be  discussed 
further  in  the  section  on  interoperability. 

Command  goals  for  the  Falcon  LAN  include:  system  expansion 
into  every  barracks  room,  limited  access  by  all  students  for 
educational  use,  electronic  mail  use,  and  remote  login  to 
educational  services  like  the  Cryptologic  Technician  Apprentice 
Common  Core  Curriculum.  Additionally,  the  LAN  should  be  configured 
to  easily  accept  future  software  and  hardware  expansion  and 
upgrades.  (Note:  The  software  and  hardware  expansion/upgrades 
will  require  the  system  to  be  re-accredited.) 

B.    SYSTEM  CONFIGURATION 

1.    Users 

The  total  number  of  personnel  supported  by  the  Falcon  LAN  is 
approximately  375.  This  includes  access  by  35  staff  personnel  and 
approximately  340  students.  The  mix  of  students  is  normally  40 
officers  and  300  enlisted  personnel.  Proposed  future  expansion  of 
the  LAN  will  also  permit  access  by  approximately  100  Marines 
stationed  at  DLI . 

Access  to  the  LAN  for  the  majority  of  staff  personnel  is 
required  between  0630  and  1700  weekdays.  The  supply  officer  is  the 
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exception  to  these  hours,  requiring  access  through  2000.   Specific 
processing  requirements  for  each  of  the  staff  offices  are: 

•  Database  Manager  and  Professional  Development:  Requires  the 
ability  to  access  the  network  for  database  management  and  to 
input  information  into  the  NSGD  student  database. 

•  Quota  Manager:  Requires  the  ability  to  access  and  update 
the  NSGD  student  database  and  the  DLI  student  database,  to 
access  the  CNET's  NITRAS  and  the  Army  ATRRS  programs,  and  to 
access  the  BUPERS  bulletin  board  and  electronic  mail 
services . 

•  Division  Officer  and  Information  Security  Manager:  Requires 
LAN  access  for  database  management  and  access  to  the  NSGD 
student  database. 

•  Supply  Officer:  The  supply  officer  is  responsible  for 
ordering  over  400  supply  items,  administering  a  $100,000  per 
year  budget  and  maintaining  all  controlled  equipage.  Unique 
requirements  for  this  office  include  the  ability  to  access 
the  supply  HICK  (hazardous  material  list) ,  FedLog  (stock 
number  access) ,  Naval  Logistics  Library,  and  Perform  Pro 
(Government  forms) . 

•  Command  Career  Counselor  and  Educational  Services  Officer: 

Requires  the  ability  to  input  information  into  the  NSGD 
student  database . 

•  Yeoman:  The  Yeomen  are  divided  into  two  sections  that 
handle  student  administration  and  command  functions.  They 
require  the  ability  to  input  information  into  the  NSGD 
student  database . 


In  addition  to  the  internal  access  requirements,  several  of 
the  staff  offices  also  require  outside  access  to  various  agencies. 
Specifically,  outside  E-mail  and  File  Transfer  Protocol  (FTP) 
access  is  required  for  the  offices  as  follows: 

•  Database  Manager  and  Professional  Development:  Access  to 
the  Chief  of  Naval  Education  and  Training  (CNET)  and  the 
Commander  Naval  Security  Group  (CNSG)  is  required. 

•  Quota  Manager:   Outside  access  is  required  with  DLI,  CNET, 
Army  NITRAS,  and  BUPERS. 
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•  Division  Officer  and  Information  Security  Manager:  Requires 
outside  access  with  DLI,  CNET,  and  CNSG. 

•  Supply  Officer:  Outside  access  is  required  with  DLI 
logistics,  DLI  Information  Management,  the  Naval 
Postgraduate  School  (NPS)  ,  CNSG,  Navy  Comptroller,  and 
commercial  vendors . 

•  Command  Career  Counselor  and  Educational  Services  Officer: 

Outside  access  is  required  with  CNET,  CNSG,  and  BUPERS . 

•  Yeoman:  Require  access  to  CNET,  CNSG,  BUPERS  Access,  DLI, 
and  NPS. 


2 .    Hardware 

a.    Computers 

Thirty  Intel  486DX2 -66  MHz  Energy  Star  Systems  provide 
access  to  the  LAN  for  the  various  LAN  users.  These  systems  include 
14 -inch  Video  Graphics  Array  (VGA)  monitors,  16  MBytes  of  Random 
Access  Memory  (RAM),  340  MByte  hard  drives,  and  Etherlink  III 
network  cards . 

Jb.    Servers 

The  LAN  servers  include  one  Pollywell  Pentium  100  MHz 
Redundant  Arrays  of  Inexpensive  Drives  (RAID)  System  set  to  RAID 
level  5  with  mirroring,  12  GBytes  of  hard  drive  space,  65  MBytes  of 
RAM,  a  CD-ROM,  and  a  tape  backup.  Two  additional  servers  are 
Pentium  100  MHz  machines  with  32  MBytes  of  RAM,  1 . 2  GB  hard  drives, 
CD-ROM,  and  a  tape  backup.  The  1.2  GB  hard  drives  are  MAXTOR 
MXT-SCSI  1240S  models  with  fast  Small  Computer  System  Interface- II 
(SCSI- II)  connections.  The  tape  backup  units  are  WANGTEX  model 
51000ES  with  a  capacity  of  1 . 0  GBytes  and  they  are  SCSI  compatible. 
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The  CD-ROM  units  are  Phillips  Sony  CM  225MS  models  and  are 
multi- session  capable. 

c.  Printers 

Three  Epson  Action  Laser  1000  printers  with  2  MBytes  of 
memory  each  provide  printing  capability  to  LAN  users.  The  printers 
can  be  upgraded  to  a  maximum  of  6.5  MBytes  of  memory  each  using  256 
KByte  chips.  The  majority  of  the  workstations  in  the  staff  offices 
have  a  local  printer  attached  and  available  for  use  by  all  LAN 
users . 

d.  Internal   Cabling 

The  Falcon  LAN  is  an  Ethernet  10Base2  network  using  Thin 
Net  RG-223  coaxial  cabling  and  BNC  connectors  to  provide  internal 
connectivity.  Links  within  building  629A  join  the  Learning  Center 
computers  used  by  Navy  students  with  office  computers  used  by  the 
Navy  staff.  Building  616,  the  Navy's  Administration  building,  uses 
Thin  Net  cabling  to  connect  a  series  of  computers  used  by  the 
Commanding  Officer  (CO) ,  Executive  Officer  (XO) ,  and  additional 
Navy  staff. 

e.  External   Cabling 

The  Presidio  of  Monterey  (POM)  Facility  Area  Network 

(FAN)  provides  the  campus  backbone  for  DLI  and  is  managed  by  the 

Directorate  of  Information  Management  (DOIM) .   Major  features  of 

the  FAN  include  an  IBM  3174  mainframe  computer,   a  48 -strand 

multi -mode  fiber  optic  backbone,  and  a  CISCO  AGS+  router  to  which 
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six  token  ring  802.5  LANs  are  attached.  The  token  ring  upon  which 
the  mainframe  is  resident  provides  a  56  Kbps  telephone  link  to  the 
NIPRNET,  the  replacement  for  the  Defense  Data  Network.  The  FAN  was 
used  to  provide  the  external  connectivity  between  buildings  629A 
and  616  as  well  as  connectivity  to  the  "outside  world"  through  the 
CISCO  router. 

DLI's  fiber  optic  plant  consists  of  a  48-strand 
multi-mode  backbone  from  building  343,  the  location  of  the  Cisco 
AGS+  router,  to  building  617,  with  connections  to  92  buildings  on 
campus,  including  buildings  616  and  629A.  An  optical  transceiver 
completes  the  connection  between  buildings  616  and  629,  and  the 
AGS+  Cisco  router  by  performing  the  required  ethernet-to-optical 
conversions  and  vice  versa. 

3.    Software 

Within  Building  629A,  30  PCs  provide  processing  capability  for 
an  estimated  400  students.  Physically  located  in  the  student 
Learning  Center,  these  computers  have  WordPerfect  6.0  and  language 
software  applications.  Additional  applications,  learning  programs 
and  electronic  mail  may  be  added  to  the  network  in  the  future. 

Windows  NT  3.51  is  the  Network  Operating  System  (NOS)  used  on 
the  servers.  In  addition  to  Windows  NT,  the  client  workstations 
use  the  Windows  95  operating  system  with  the  following  applications 
available  to  staff  personnel:  WordPerfect  6.0,  MS  Office 
Professional  with  Bookshelf,  Lotus  123,  and  Harvard  Graphics.  The 
Structured  Query  Language  (SQL)  server  provides  access  to  SQL, 
Paradox,  NITRAS,  ATRRS,  and  Harvard  Graphics. 

63 


C.    CLASS  C2  REQUIREMENT 

The  National  Security  Agency  (NSA)  has  stipulated  that  all 
computer  systems  operated  by  cryptologic  organizations  must  achieve 
the  following  minimum  level  of  trust  by  calendar  year  2000:  [Ref . 
18] 


Operational  Mode  Class  of  Trust 
Dedicated  C2 

System  High  C2 

Compartment ed  Bl 

Multilevel  B2 


According  to  the  Information  System  and  Network  Security  Procedures 
for  Service  Cryptologic  Elements  [Ref.  18],  the  Falcon  LAN  is 
categorized  as  a  cryptologic  Automated  Information  System  (AIS) 
since  it  directly  supports  the  efforts  of  the  cryptologists 
assigned  to  DLI .  Although  the  information  stored  on  the  Falcon 
LAN  will  be  unclassified,  due  to  the  sensitivity  of  Privacy  Act 
information  it  should  be  considered  as  operating  in  the  System  High 
mode.  This  classification  would  be  used  since  all  system  users  will 
have  the  appropriate  clearance  (in  this  case  unclassified)  ,  but 
some  will  not  have  a  valid  "need-to-know"  for  some  of  the  data 
contained  in  the  system.  Therefore,  the  Falcon  LAN  would  be 
required  to  meet  the  Class  C2  requirements  by  calendar  year  2000. 

D.    WINDOWS  NT  VERSION  3.51  OVERVIEW 

Windows  NT  Workstation  and  Windows  NT  Server  are  32 -bit, 
graphical  oriented  operating  systems  which  support  popular  Windows - 
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based  applications,  preemptive  multitasking,  and  symmetric 
processing.  [Ref .  19]  "Windows  NT  Workstation  is  optimized  to 
provide  a  high  level  of  interactive  application  responsiveness, 
while  Windows  NT  Server  provides  optimized  network  responsiveness." 
[Ref.  20:  p.  4]  Specific  workstation  features  which  were  optimized 
(when  compared  to  earlier  versions  of  the  software  and  other 
network  operating  systems)  include  overall  reduction  of  memory 
usage,  higher  system  priorities  for  interactive  applications,  and 
improved  efficiency  of  both  16 -bit  and  32 -bit  applications. 
Similarly,  the  server  features  which  were  optimized  include 
improved  memory  usage  (by  caching  large  amounts  of  data) ,  higher 
system  priorities  for  network  users,  and  improved  efficiency  for 
32-bit  server  operations.  Normally  the  name  Windows  NT  is  used  to 
reference  both  products. 

Both  Windows  NT  Server  and  Windows  NT  Workstation  were  tested 
by  the  NCSC  for  Class  C2  compliance  with  the  requirements  set  forth 
in  the  TCSEC .  The  hardware  platforms  used  in  the  evaluation 
included  two  different  processor  architectures:  Intel  Pentium 
microprocessor  (Compaq  Proliant  2000  and  4000  (Pentium) )  and  the 
DEC  Alpha  AXP/150  with  the  DECchip  2106-AA  processor.  It  is 
important  to  note  that  the  testing  performed  was  for  a  stand-alone 
configuration  only.  Therefore,  Class  C2  compliance  in  a  networked 
environment  using  Windows  NT  has  not  been  granted.  The  Final 
Evaluation  Report  [Ref.  21]  of  14  February  1996,  was  written  by  the 
NCSC  evaluation  team  and  provides  a  comprehensive  summary  of  the 


65 


results  for  the  overall  evaluation.  It  was  the  primary  reference 
used  throughout  this  section. 

Before  evaluating  Windows  NT  and  the  Falcon  LAN  against  the 
TCSEC,  an  overview  of  the  Windows  NT  software  is  needed.  The 
following  sections  are  provided  to  create  a  foundation  for  the 
evaluation  that  is  conducted  in  Section  E  of  this  chapter. 

1.    The  Trusted  Computing  Base  (TCB) 

Three  components  make  up  the  Windows  NT  Trusted  Computing  Base 
(TCB) :    [Ref .  21:  p.  5] 

•  Executive:   runs  the  processor  privileged  state  or  kernel 
mode. 

•  Protected   Servers:       run  the  processor  unprivileged  state, 
called  user-mode. 

•  Administrator  Tools:      run  in  user  mode. 

Figure  3  provides  a  graphical  representation  of  the  overall  TCB. 
Due  to  space  limitations,  not  every  executive  subsystem  or 
individual  protected  server  has  been  drawn.  However,  the  I/O 
Subsystem  and  Memory  Manager  have  been  identified  to  show  the 
interaction  with  the  hardware.  In  addition,  it  should  be  noted 
that  the  device  drivers,  microkernel,  memory  manager,  and  Hardware 
Abstraction  Layer  are  all  hardware  dependent. 

a.    The  Executive 

The  executive  is  further  divided  into  three  conceptual  layers 
which  are  referred  to  as  the  Hardware  Abstraction  Layer  (HAL) ,  the 
Microkernel,  and  the  "rest"  of  the  executive  or  executive 
subsystems . 
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The  HAL  "provides  an  abstract  view  of  the  underlying  machine 
architecture  to  the  executive,  allowing  for  a  machine -independent 
implementation  of  Windows  NT  executive  (thereby  allowing  Windows  NT 
to  be  easily  ported  within  machines  of  similar  architectures." 
[Ref .  21:  p.  5]  The  information  provided  to  the  executive  by  the 
HAL  includes  machine- specif ic  details  regarding  functions  such  as 
device  Input /Output  (I/O) ,  processor  initialization,  and 
interrupts . 


ADMINISTRATOR  TOOLS 


PROTECTED  SERVERS 


User -mode 


Kernel -mode 


EXECUTIVE 


I/O 
Subsystem 


I/O  Manager 
Cache  Manager 
File  Systems 
Device  Driver 


Executive  Subsystems 


Microkernel 


Memory 
Manager 


Hardware  Abstraction  Layer 


HARDWARE 


Figure  3.   Windows  NT  Operating  System  Overview  [Ref.  21:  p.  6] 
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The  Microkernel  provides  the  foundation  for  the  rest  of  the 
executive  subsystems,  giving  low-level  support  for  execution, 
interrupt  and  exception  handling,  and  synchronization.  Some  of  the 
primitive  objects  created  by  the  Microkernel  are  exported  to  user- 
mode  programs  from  the  executive  by  the  Executive  Object  Services 
and  Process  Manager. 

The  executive  subsystems  include  the  following: 

•  Object  Manager:  The  Object  Manager  is  responsible  for  the 
creation,  access,  and  deletion  of  objects  used  within  the 
executive  and  exported  from  the  executive.  The  Object 
Manager  is  also  responsible  for  managing  handles  and  handle 
tables.  Every  process  has  a  handle  table  which  identifies 
the  objects  currently  accessed  by  it.  For  a  process  to  gain 
access  to  an  executive  object,  the  process  must  first 
acquire  a  handle  (a  ticket  that  permits  access)  from  the 
Object  Manager.  The  Object  Manager  works  with  the  Security 
Reference  Monitor  to  validate  if  the  process  is  authorized 
access,  generates  the  handle  (if  permitted) ,  and  then  adds 
the  handle  to  the  object's  handle  table.  The  handle 
identifies  the  type  of  access  allowed  (i.e.,  read,  write, 
execute)  and  limits  the  type  of  access  to  only  those 
permitted.  The  Object  Manager  manages  three  types  of 
objects:  type,  directory,  and  symbolic  link.  The  "type" 
object  is  used  only  within  the  executive.  It  provides  the 
executive  subsystems  with  the  ability  "to  create  classes  of 
objects  (e.g.,  directories,  files,  processes,  semaphores) 
and  define  their  semantics."   [Ref.  21:  p.  7] 

•  Security  Reference  Monitor:  This  subsystem  generates  the 
checks  for  access  control  and  privilege  validation  and  is 
also  responsible  for  audit  generation.  The  Security 
Reference  Monitor  exports  security  services  to  user-mode 
processes  through  the  generation  of  tokens  which  are  used  by 
the  protected  servers  to  validate  access  requests,  check 
authorized  privileges,  and  generate  audits  for  the  user- 
mode  . 

•  Process  Manager:  "Windows  NT  executive  provides  multi- 
threaded processes.  Essentially,  a  process  is  a  private 
virtual  address  space,  associated  physical  memory,  and  a  set 
of  accessible  objects.  A  thread  is  a  point  of  execution 
within  a  process,  and  includes  all  necessary  execution 
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context  information  (e.g.,  registers,  stack  pointers).  A 
process  may  have  zero  or  more  threads."  [Ref .  21:  p.  7]  A 
process  with  no  threads  cannot  execute.  The  Process  Manager 
exports  both  processes  and  threads  as  executive  objects. 

•  Virtual  Memory  Manager:  This  subsystem  provides  a  demand- 
paged  memory  management  system  for  the  executive.  Every 
process  has  a  private  page  table  directory  which  identifies 
the  location  of  various  page  tables.  The  page  tables  in 
turn  identify  the  location  of  pages  of  memory.  Combined, 
the  page  table  directories  and  page  tables  are  used  to 
identify  memory  locations.  Page-level  memory  protection 
features  are  included  for  read,  write,  and  execute  access. 
Sections  of  shared  memory  between  processes  are  exported  by 
the  Virtual  Memory  Manager  as  an  executive  object  type. 

•  Local  Procedure  Call  (LPC)  Facility:  Communication  between 
processes  is  supported  through  the  LPC  Facility.  It  may 
export  executive  object  ports  for  communication  support 
outside  of  the  executive. 

•  Input/Output  (I/O)  Subsystem:  The  I/O  subsystem  includes 
the  I/O  Manager,  the  file  systems,  and  the  various  device 
drivers;  and  provides  packet -driven,  asynchronous  I/O.  Some 
device  drivers  may  have  a  layered  structure,  with  each  layer 
depending  upon  the  services  of  the  lower  layers.  The  I/O 
Manager  facilitates  the  communication  between  the  layers. 
The  Cache  Manager  is  used  by  the  file  system  to  support 
memory-mapped  I/O  and  provide  a  memory-based  cache. 

•  Configuration  Manager:  The  Configuration  Manager  maintains 
the  system  configuration  information  through  a  registry. 
The  registry  is  implemented  in  a  tree -structured  database 
that  is  indexed  by  keys.  Keys  are  the  executive  type  object 
which  may  be  exported  by  the  Configuration  Manager. 

•  Executive  Object  Services:  The  Executive  Object  Services 
along  with  the  Process  Manager  provide  interfaces  between 
the  user-mode  and  exported  executive  objects. 


b.         Protected  Servers 

Protected  Servers  are  user-mode  processes  which  provide 
security  relevant  services.  The  Protected  Servers  which  were 
included  in  the  Windows  NT  software  evaluated  by  NCSC  included: 
the  Local  Security  Authority  (LSA)  subsystem,  WinLogon,  Win32,  the 
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Security  Accounts  Manager  (SAM) ,  the  Print  Spooler,  the  Session 
Manager,  the  Service  Controller,  and  the  Event  Logger.  [Ref .  21: 
p.  8]  The  following  provides  a  brief  description  of  each  protected 
server : 


•  Local  Security  Authority  (LSA)  :  Maintains  the  list  of  valid 
user  identifiers  and  their  associated  passwords.  It  is  also 
used  to  collect  and  store  audit  records. 

•  WinLogon:  Coordinates  user  authentication  upon  login  by 
prompting  the  user  for  an  identifier  and  password.  The 
information  is  validated  by  the  LSA  before  system  access  is 
permitted. 

•  Win32 :  Provides  the  interface  to  Windows  NT  through  two 
user-mode  exported  objects,  WindowStation  and  DeskTop.  The 
WindowStation  object  provides  the  means  for  a  user  to  access 
and  manipulate  the  various  system  resources,  such  as  the 
keyboard,  mouse,  and  display.  The  DeskTop  object  provides 
the  user  with  abstract  resources  such  as  menus,  windows,  and 
title  bars.  Every  DeskTop  object  must  have  an  associated 
WindowStation  object.  Both  types  of  objects  are  protected 
and  audited  through  the  use  of  services  provided  by  the 
Security  Reference  Monitor. 

•  Security  Accounts  Manager  (SAM) :  Provides  security 
administration  of  user  accounts. 

•  Print  Spooler:  Routes  print  requests  to  the  appropriate 
printer. 

•  Session  Manager:  Initiates  the  WinLogon  and  Win32  protected 
servers  during  system  initialization  and  starts  other  system 
processes  as  needed.  The  Session  Manager  works  with  the 
WinLogon  and  Service  Controller  to  authenticate  user  access 
and  identify  security  attributes. 

•  Service  Controller:  Manages  drivers  and  services  by 
monitoring  the  current  status  of  each.  Also  ensures  the 
loading  of  all  drivers  which  require  automatic  loading  at 
boot -time . 

•  Event  Logger:  Writes  audit  records  into  a  log  file  and 
provides  services  for  processes  to  enter  events  into  the 
log.  Services  are  also  provided  for  the  log  entries  to  be 
viewed  by  authorized  personnel . 


70 


c. 


Administrator  Tools 


Backup 

Provides  functions  to  back  up  disk  files  to 
tape,  restore  tape  files  to  disk,  label,  track, 
and  identify  tapes. 

Chkdsk 

Checks  for  and  identifies  file  integrity 
problems;  also  examines  security  descriptor 
information  of  NTFS  partitions. 

Control  Panel 

Permits  users  to  customize  and  administer 
Windows  NT;  security  relevant  features  include 
the  administration  of  the  computer  clock, 
device  drivers,  ports,  print  manager,  Registry 
services,  and  system  performance  parameters. 

Disk 
Administrator 

Provides  functions  to  partition  disks,  create 
and  delete  volume  sets,  extend  volume  sets, 
create  and  delete  stripe  sets,  establish  and 
break  mirror  sets,  and  recover  data. 

Event  Viewer 

Allows  for  viewing,  sorting,  filtering,  and 
searching  event  logs . 

File  Manager 

Provides  file  and  directory  manipulation  and 
organization  functions. 

Print  Manager 

Provides  functions  to  manage  printing, 
printers,  and  print  jobs. 

Program 
Manager 

Basic  user  interface  used  to  organize  the 
applications  and  files  in  groups  and  to  start 
the  applications  easily. 

Registry- 
Editor 

Used  to  view  and  edit  the  configuration 
database. 

Setup 

Used  to  accomplish  the  original  installation  of 
Windows  NT;  allows  administrators  to  make 
several  configuration  changes. 

User  Manager 

Used  to  create  and  manage  user  accounts  and 
groups,  and  to  implement  the  security  policy. 

Table  4.   Administrator  Tools  [Ref .  21:   pp.  128  -  131] 


The  Administrator  Tools  provide  resources  for  managing  all 
aspects  of  the  Windows  NT  System.  Included  are  tools  for  managing 
user  accounts,  auditing  the  system  configuration,  performing  file 
system  backups,  and  reviewing  audit  records.   The  specific  set  of 
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tools  which  were  included  in  the  NCSC  evaluation  were:  "Backup, 
Chkdsk,  Control  Panel,  Disk  Administrator,  Event  Viewer,  File 
Manager,  Print  Manager,  Program  Manager,  Registry  Editor,  Setup, 
and  User  Manager."  [Ref.  21:  p.  9]  Table  4  provides  a  brief 
description  of  each  of  these  tools. 

d.    TCB  Interfaces 

There  are  three  methods  through  which  an  untrusted  subject  may- 
request  services  from  the  TCB: 

•  Unprivileged  Hardware  Instructions:  The  untrusted  subject 
may  invoke  any  unprivileged  hardware  instruction  (e.g., 
arithmetic  operations) . 

•  Windows  NT  Executive  System  Services:  The  untrusted  subject 
may  make  a  call  to  the  executive  system  services. 

•  Interprocess  Communication  (IPC) :  The  untrusted  subject  may 
make  a  request  of  one  of  the  protected  servers . 

A  large  set  of  Dynamic  Link  Libraries  (DLLs)  provide  the 
programming  interface  to  the  Windows  NT  system.  When  a  function  is 
initiated  by  one  of  the  DLLs,  it  will  result  in  at  least  one  of  the 
above  service  requests. 

2.    Subjects 

In  Windows  NT,  a  subject  is  a  process  with  one  or  more 
threads.  Each  process  has  an  associated  virtual  address  space,  a 
private  handle  table,  and  a  security  context.  Every  thread  within 
the  process  has  equal  access  to  the  address  space  and  private 
handle  table.  Security  context  information  is  provided  by  access 
tokens  which  contain  access  control  and  privilege  information. 
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Every  process  has  exactly  one  primary  token  which  represents  the 
current  user  and  his  or  her  authorized  access  permissions. 

Windows  NT  also  permits  a  technique  referred  to  as 
impersonation  in  which  one  process  may  adopt  the  security 
attributes  of  another  process.  For  example,  this  may  occur  when  a 
server  process  impersonates  a  client  process  in  order  to  obtain 
access  to  objects  maintained  on  the  client.  Each  thread  within  a 
process  may  have  one  impersonation  token  which  is  used  to 
accomplish  this  task. 

3.    Objects 

Two  broad  categories  of  objects  are  used  by  Windows  NT: 
executive  objects  and  server  objects.  The  executive  objects  are 
created,  managed,  and  protected  by  the  various  executive  subsystems 
and  the  server  objects  are  created  and  maintained  by  the  user-mode 
protected  servers.  The  Object  Manager  and  Security  Reference 
Monitor  provide  access  mediation  for  all  executive  objects.  In 
contrast,  server  objects  are  protected  by  the  corresponding  TCB 
protected  server  which  may  request  services  from  the  Security 
Reference  Monitor  in  the  executive.  Table  5  provides  a  breakdown 
of  the  various  types  of  objects  and  the  corresponding  subsystem 
which  is  responsible  for  the  object's  security  and  management. 
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Executive  Object  Types 

Object   Type 

Managing  Subsystem 

Event 

Executive  Object  Services 

Event  Pair 

Executive  Object  Services 

I/O  Completion  Port 

Executive  Object  Services 

Key 

Configuration  Manager 

Mutext 

Executive  Object  Services 

Object  Directory 

Object  Manager 

Object  Symbolic  Links 

Object  Manager 

Port 

Local  Procedure  Call  Facility 

Process 

Process  Manager 

Profile 

Executive  Object  Services 

Section 

Memory  Manager 

Semaphore 

Executive  Object  Services 

Thread 

Process  Manager 

Timer 

Executive  Object  Services 

Tokens 

Security  Reference  Monitor 

Device 

I/O  Manager  and  Device  Drivers 

Mailslot 

Mailslot  File  System 

Named  Pipe 

Named  Pipe  File  System 

NTFS  File 

Windows  NT  File  System 

NTFS  Directory 

Windows  NT  File  System 

Protected  Server  Obj 

ect  Types  (user  accessible) 

Object   Type 

Managing  Server 

Log 

Event  Logger 

Service 

Service  Controller 

Desktop 

Win32  Server 

Print  Job 

Print  Spooler 

Printer 

Print  Spooler 

Print  Server 

Print  Spooler 

Windows tat ion 

Win32  Server 

Table  5.   Windows  NT  Protected  Objects  [Ref .  21:  p.  141] 


Every  object  may  have  one  or  more  of  the  following  attributes 
associated  with  it: 


Owner  ID:  Identifies  the  owner  of  the  object.  The  owner 
may  be  an  individual,  a  global  group,  or  a  local  group.  The 
owner  always  has  the  WriteDAC  and  ReadControl  permissions 
for  the  object.  WriteDAC  allows  the  DACL  to  be  modified  and 
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ReadControl  allows  an  object's  security  information  to  be 
read. 

•  Discretionary  Access  Control  List  (DACL) :  The  DACL  provides 
the  primary  means  for  controlling  access  to  an  object.  The 
DACL  entry  identifies  the  permissions  granted  or  explicitly 
denied  to  a  user  or  group  of  users . 

•  System  Access  Control  List  (SACL) :  A  system  administrative 
structure,  the  SACL  is  used  to  control  security  auditing  for 
the  object. 

•  Group  ID:  Used  to  provide  compatibility  with  certain 
operating  system  standards,  such  as  POSIX.  It  has  no 
security  relevance. 

Container  and  non- container  are  two  additional  terms  which  are 
used  to  define  objects  within  Windows  NT.  Specifically,  a 
container  object  is  one  which  logically  contains  other  objects. 
For  example,  a  directory  would  be  defined  as  a  container  object 
since  it  contains  files.  In  turn,  the  files  are  examples  of  non- 
container  objects  since  they  do  not  contain  other  objects.  [Ref. 
22] 

4.    Object  Access  Rights 

An  access  mask  is  the  DACL  entry  used  to  denote  the  types  of 
access  permitted  or  denied  to  an  object.  A  standard  structure  is 
used  for  all  types  of  objects  to  ensure  the  "Security  Reference 
Monitor  (SRM)  can  perform  access  validation  regardless  of  the 
specific  object  type."  [Ref.  21:  p.  142]  Although  the  access  mask 
structure  is  standard,  the  meaning  of  some  fields  within  the  mask 
may  be  type  specific  and  are  defined  by  the  executive  subsystem  or 
protected  server  responsible  for  managing  the  object. 
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Five  types  of  access  rights  may  be  specified  by  an  access 
mask:  standard,  specific,  generic,  Maximum  Allowed  (MA) ,  and 
Access  system  Security  (AS) .  MA  and  AS  rights  are  used  only  with 
requests  for  access  to  an  object.  Specifically,  MA  is  used  to 
request  all  permitted  access  rights  to  the  object  and  AS  is  used  to 
request  access  to  the  object's  SACL. 

The  standard  access  rights  are  interpreted  the  same  for  all 
objects,  regardless  of  type,  and  include  five  permissions:  [Ref . 
21:  p.  143] 

•  Delete:   Permits  an  object  to  be  deleted. 

•  ReadControl:  Permits  an  object's  security  related 
information  (e.g.,  owner,  DACL)  to  be  read. 

•  WriteDAC:   Permits  modification  of  the  DACL. 

•  WriteOwner:  Permits  a  thread  to  change  the  ownership  of  an 
object  to  any  security  identifier  within  the  thread's 
current  token . 

•  Synchronize:  Permits  the  object  to  be  used  for  process 
synchronization . 

The  synchronize  permission  is  normally  used  only  for  specific  types 
of  objects  such  as  communication  or  process  objects.  The  other 
four  permissions  are  used  for  all  types  of  objects. 

Specific  access  rights  are  completely  type-specific  and  have 
no  general  meaning.  The  access  mask  may  contain  up  to  16 
permissions  which  are  defined  by  the  responsible  executive 
subsystem  or  protected  server. 

Finally,  generic  access  rights  are  not  actually  access  rights 
to  an  object,  but  rather  a  reference  to  standard  and/or  specific 
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rights .  The  reference  is  a  mapping  to  a  subset  of  the  other 
rights.  There  are  four  generic  access  rights:  GenericRead, 
GenericWrite,  GenericExecute,  and  GenericAll .  GenericAll  is 
structured  to  map  to  all  of  the  standard  and  specific  rights  of  the 
specified  object  type. 

5 .    Privileges 

"Privileges  are  stored  in  a  process'  token  and  allow  a  thread 
to  take  exception  to  an  object's  DACL  or  utilize  restricted 
services."  [Ref .  21:  p.  151]  The  privileges  of  a  process  are 
determined  by  the  privileges  assigned  to  the  account  of  the  user 
who  has  invoked  the  process.  A  privilege  may  be  used  by  a  thread 
at  any  time.  The  subsystem  which  implements  and  audits  the 
privilege  is  referred  to  as  the  enforcer.  Examples  of  privileges 
are : 

•  CreateToken:   Creates  a  token;  enforced  by  the  SRM. 

•  AssignPrimaryToken:  Assigns  the  primary  token  of  a  process; 
enforced  by  the  Process  Manager. 

•  Security:  Identifies  the  holder  as  a  security  operator, 
permitting  access  to  SACLs  and  the  audit  log;  enforced  by 
Win32,  Object  Manager,  SRM,  NTFS,  Event  Logger. 

•  LockMemory:  Locks  physical  pages  in  memory;  enforced  by  the 
Memory  Manager. 

•  Backup:   Needed  to  perform  backup  operations;  enforced  by 
the  Configuration  Manager,  I/O  subsystem,  and  NTFS. 

•  SystemTime:  Permits  the  system  time  to  be  changed;  enforced 
by  the  Executive  Object  Services. 
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6.  File  System  Types 

Windows  NT  supports  five  distinct  types  of  file  systems 
including  the  File  Allocation  Table  (FAT)  system,  the  Windows  NT 
File  System  (NTFS) ,  the  CD-ROM  File  System  (CDFS) ,  the  Named  Pipe 
File  System  (NPFS) ,  and  the  Mailslot  File  System.  NTFS  is  a  new 
file  system  which  was  specifically  designed  for  Windows  NT.  It  is 
not  supported  on  floppy  diskettes  and  only  NTFS  files  are  protected 
by  Discretionary  Access  Control  (DAC) . 

Any  environment  with  security  concerns  should  use  the  NTFS 
file  system  because  it  provides  more  security  features  than  the 
standard  FAT  system.  If  a  FAT  system  is  used,  the  Secure  System 
Partition  command  from  the  Disk  Administrator  utility  may  be  used 
to  partition  the  FAT  in  its  entirety. 

7.  C2Config.EXE 

To  assist  with  establishing  a  Class  C2  compliant  system,  an 
application  called  C2Conf ig  was  created  and  included  in  the  Windows 
NT  Resource  Kit  [Ref .  23] .  The  program  allows  the  user  to  select 
and  implement  the  appropriate  settings  for  Class  C2  security.  A 
graphical  display  with  a  lock  next  to  each  security  aspect 
indicates  which  requirements  have  been  satisfied  (locked)  and  which 
requirements  have  not  been  met  (unlocked)  .  In  addition  to  the 
indication  of  being  locked  or  open,  a  color  scheme  is  used  to 
denote  which  requirements  are  mandatory  for  Class  C2  compliance. 
Specifically,  a  red  lock  indicates  an  explicit  requirement  and  a 
blue  lock  represents  an  optional  feature.   The  various  attributes 
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and  their  descriptions  as  defined  on  screen  by  the  Windows  NT 
Resource  Kit  are:   [Ref .  23] 


•  File  Systems  (Required)  :  Under  Windows  NT,  only  the  NT  File 
System  (NTFS)  supports  DAC  to  the  files  and  directories. 
Consequently,  only  NTFS  volumes  are  allowed  on  the  system  to 
provide  secure  and  auditable  access  to  the  files.  FAT 
volumes  do  not  provide  the  necessary  security  functions  to 
support  Class  C2  level  security. 

•  OS  Configuration  (Required) :  Allowing  other  operating 
systems,  such  as  MS-DOS  to  run  on  a  secure  system,  can  allow 
users  to  circumvent  Windows  NT  security.  For  a  system  to 
support  Class  C2  level  security,  Windows  NT  must  be  the  only 
operating  system  on  the  computer. 

•  OS/2  Subsystem  (Required)  :  The  OS/2  subsystem  was  not 
included  in  the  current  NCSC  Class  C2  evaluated 
configuration.  For  a  system  to  conform  to  the  evaluated 
configuration,  the  OS/2  system  must  be  disabled.  The 
C2Conf iguration  manager  disables  the  OS/2  subsystem  by 
deleting  the  following  files  from  the  SYSTEM32  directory 
under  the  systemroot:   0S2.EXE  and  0S2SS.EXE. 

•  POSIX  Subsystem  (Required) :  The  POSIX  subsystem  was  not 
included  in  the  current  NCSC  Class  C2  evaluated 
configuration.  For  a  system  to  conform  to  the  evaluated 
configuration,  the  POSIX  system  must  be  disabled.  The 
C2Conf iguration  manager  disables  the  POSIX  subsystem  by 
deleting  the  following  files  from  the  SYSTEM32  directory 
under  the  systemroot:   PSXSS.EXE. 

•  Security  Log  (Required) :  Class  C2  level  security  requires 
that  a  security  audit  log  be  maintained  and  the  events  in 
the  log  may  not  be  automatically  overwritten.  For  systems 
that  do  not  require  Class  C2  level  security,  other  logging 
options  may  be  selected  such  as  to  overwrite  events  that  are 
older  than  a  certain  age  or  when  the  log  is  full . 

•  Halt  on  Audit  Failure  (Optional) :  If  the  security  log  is 
full,  it  becomes  possible  for  some  events  to  not  be  logged. 
Selecting  this  option  will  halt  the  computer  when  the  log  is 
full  to  prevent  losing  any  events.  If  the  system  halts  as 
a  result  of  a  full  log,  an  administrator  must  restart  the 
system  and  reset  the  log. 

•  Display  Logon  Message  (Optional) :  On  a  secured  system,  a 
warning  message  may  be  displayed  before  the  user  is  allowed 
to  log  on.  Typically  this  message  will  inform  the  user  that 
the   system   is   authorized   for   users   only   and   that 
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unauthorized  use  is  considered  trespass  or  is  unwelcomed. 
In  contrast,  if  the  system  is  used  in  a  public  forum,  the 
message  may  be  used  to  inform  the  user  of  current  events  or 
how  to  log  onto  the  system. 

•  Last  Username  Display  (Optional) :  Displaying  the  name  of 
the  last  user  can  make  logging  in  more  convenient,  however, 
hiding  the  name  of  the  last  user  can  prevent  usernames  from 
being  accidentally  discovered  and  subsequently  used  to  break 
into  the  system.  This  option  allows  the  username  to  be 
hidden  when  the  logon  screen  is  displayed. 

•  Shutdown  Button  (Optional)  :  Hiding  the  shutdown  button  from 
the  logon  screen  prevents  users  from  shutting  the  system 
down  without  first  logging  onto  the  computer.  This  option 
should  only  be  selected  if  the  power  switch  and  reset  button 
is  not  accessible  by  the  user.  Even  though  the  shutdown 
button  may  be  hidden,  if  the  user  has  access  to  either  the 
reset  button  or  the  power  switch,  they  may  still  turn  the 
system  off  without  properly  shutting  down  the  operating 
system. 

•  Password  Length  (Required) :  The  longer  the  password,  the 
less  likely  it  will  be  discovered  randomly,  or  deliberately 
by  an  intruder.  Class  C2  level  security  does  not  allow 
Blank  Passwords.  Using  this  item,  the  desired  password 
policy  can  be  selected. 

•  Guest  Account  (Required) :  The  Guest  account  allows 
anonymous  and  therefore  unauditable  access  to  the  system  and 
its  files.  Class  C2  level  security  does  not  allow  for 
anonymous  access  to  the  system  and  therefore  requires  the 
Guest  account  to  be  disabled  or  deleted  from  the  system. 
When  this  item  is  selected,  the  Class  C2  Configuration 
manager  disables  all  Guest  accounts. 

•  Networking  (Required) :  Not  currently  cleared  for  networks . 

•  Drive  Letters  and  Printers  (Optional) :  To  prevent 
redirection  of  data  to  a  device  or  port  that  may  not  be 
authorized,  the  assignment  of  drive  letters  and  printer 
ports  can  be  restricted  to  administrators  only. 

•  Removable  Media  Drives  (Optional) :  Since  Windows  NT  is  a 
multi-user  system,  programs  run  by  other  users  may  be 
running  in  the  background  while  a  user  is  logged  on.  It  is 
possible  to  prevent  programs  run  by  other  users  from 
accessing  disks  in  removable  media  drives  that  may  have  been 
inserted  while  a  user  is  logged  on  by  allocating  these 
drives  automatically  when  a  user  logs  on. 
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E.    EVALUATING  THE  LEVEL  OF  TRUST 

Since  the  computer  system  implemented  at  DLI  is  a  network,  the 
TCSEC  criterion  as  interpreted  in  the  TNI  must  be  used  to  determine 
if  the  system  meets  the  Class  C2  requirements.  The  following 
sections  provide  a  breakdown  of  these  criterion  with  an  evaluation 
of  the  Falcon  network.  Since  the  Network  Operating  System  (NOS)  is 
the  primary  controller  of  access  to  the  various  objects  (including 
applications)  on  the  network,  the  focus  of  this  evaluation  is  on 
Windows  NT  version  3.51. 

1.    Security  Policy 

The  first  requirement  of  the  TCSEC  specifically  states  that  a 
system  must  have  an  "explicit  and  well-defined  security  policy 
enforced  by  the  system."  [Ref .  5:  p.  3]  This  means  that  with  the 
set  of  all  identified  subjects  and  objects  within  the  system,  there 
must  exist  a  set  of  rules  which  are  used  by  the  system  to  determine 
whether  or  not  a  subject  should  be  permitted  access  to  an  object. 
At  the  Class  C2  level  of  trust,  this  policy  will  be  discretionary 
and  will  be  enforced  using  the  Discretionary  Access  Control  (DAC) 
and  Object  Reuse  requirements,  at  a  minimum.  The  information  will 
be  protected  to  the  granularity  of  individual  access  rights.  In 
addition,  the  policy  implementation  will  describe  network  features 
which  prevent  or  detect  the  unauthorized  reading  or  destruction  of 
sensitive  information. 

It  should  be  noted  that  the  TNI  does  not  include  operators, 
system  programmers,  technical  control  officers,  and  system  security 
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officers  under  the  title  of  users.  These  positions  are  considered 
support  personnel  and  are  subject  to  the  requirements  of  the 
Trusted  Facility  Manual  and  the  System  Architecture.  [Ref .  15:  p. 
16] 

The  network  security  policy  may  require  data  secrecy,  data 
integrity,  or  both.  The  secrecy  policy  defines  the  DAC  mechanisms 
used  to  prevent  the  unauthorized  reading  of  sensitive  information, 
and  the  data  integrity  policy  defines  the  mechanisms  used  to 
prevent  the  unauthorized  modification  (i.e.,  writing)  of  sensitive 
information.  Due  to  the  amount  of  sharing  in  a  networked 
environment,  the  integrity  of  the  data  stored  is  just  as  important 
as  the  secrecy  of  the  data.  Therefore,  most  networks  will  address 
both  data  secrecy  and  data  integrity  in  the  overall  security 
policy. 

a.    Discretionary  Access  Control    (DAC) 

Requirement:  The  DAC  portion  of  the  security  policy  must 
define  and  control  the  access  of  objects  by  subjects  within  the 
system  to  the  individual  user  level.  Groups  of  individuals  may 
also  be  given  control  rights,  provided  the  individual  members  of 
the  groups  are  identified  by  the  group  name.  This  includes  network 
identifiers  such  as  internet  addresses  for  various  components  of 
the  network.  In  addition,  the  DAC  mechanism  must  limit  the 
propagation  of  access  rights  with  only  authorized  subjects  being 
permitted  to  grant  access  rights  to  unauthorized  users  of  an 
object . 
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Windows  NT  Features:  Windows  NT  uses  Discretionary  Access 
Control  Lists  (DACLs)  to  regulate  access  between  subjects  and 
objects  with  access  controlled  to  the  granularity  of  an  individual 
user.  The  entries  are  used  only  with  the  NTFS  file  system.  Each 
entry  represents  access  granted  or  explicitly  denied  to  a  user  or 
group  of  users.  The  DACL  also  permits  users  to  share  objects  with 
other  users  or  groups  of  users.  The  owner  of  an  object  or  any  user 
with  WriteDAC  access  to  the  object,  may  define  access  restrictions 
on  the  object.  NT  does  not  require  every  object  to  have  a  DACL 
associated  with  it.  If  an  object  does  not  have  a  DACL,  then  any 
user  who  is  able  to  name  and  open  the  object  is  permitted  all 
access  rights.  This  is  not  the  same,  however,  as  an  empty  DACL 
which  means  no  one  has  access  to  the  object. 

The  DAC  policy  is  enforced  by  the  Security  Reference  Monitor 
(SRM)  .  When  access  to  an  object  is  requested  by  a  subject,  the  SRM 
compares  the  subject's  token  to  the  object's  DACL.  If  the  subject 
is  requesting  access  to  an  executive  object,  the  request  must  be 
made  through  the  Object  Manager  which  in  turn  performs  the 
validation  with  the  SRM.  Once  it  has  been  determined  that  access 
is  permitted,  a  handle  is  created  and  access  is  granted  (see 
section  D.l.a,  Object  Manager  description) .  After  a  handle  has  been 
stored  for  a  subject  in  the  executive  object's  handle  table,  all 
subsequent  access  requests  are  verified  by  using  the  access  mask 
that  is  stored  as  part  of  the  handle. 

If  the  subject  is  requesting  access  to  a  protected  server 
object,  the  object  must  be  opened  before  access  is  permitted.  Once 
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the  request  is  made  by  the  subject,  the  protected  server  sends  a 
validation  request  to  the  SRM  to  verify  that  access  is  authorized. 
If  access  is  permitted,  the  SRM  exports  a  handle  with  the 
appropriate  information  and  the  object  is  opened  (i.e.,  access  is 
granted) .  Unlike  the  executive  objects,  this  process  must  be 
accomplished  for  all  subsequent  requests  by  the  subject  as  well. 

There  are  six  privileges  which  may  override  the  rights  listed 
in  the  DACL.  If  any  of  these  privileges  are  enabled  on  the  primary 
or  impersonation  token  of  the  subject  requesting  access,  the  DACL 
is  overridden.  The  exception  privileges  include  TakeOwnership, 
Security,  Backup,  Restore,  Debug,  and  ChangeNotify . 

When  an  object  is  created,  the  DACL  may  be  directly  assigned, 
assigned  by  default,  or  inherited.  If  directly  assigned,  the 
parameters  which  define  the  DACL  are  passed  by  the  object  create 
system  call.  The  default  assignment  is  used  for  objects  which  are 
required  to  have  a  DACL.  This  includes  all  named  executive 
objects,  server  objects,  process,  thread,  and  token  objects.  When 
the  object  is  created,  the  values  assigned  to  the  DACL  are  based 
upon  the  user  creating  the  object,  any  explicit  values  provided  in 
the  create  process,  default  values  from  the  creating  process  token, 
and  any  inheritable  DACL  information.  Finally,  sub-objects  of 
container  objects  may  inherit  DACL  information  from  the  container 
or  parent  object.  Control  flags  which  are  part  of  the  DACL  entry 
may  be  used  to  limit  the  amount  of  inheritance  permitted. 
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Jb.    Object  Reuse 

Requirement:  Object  reuse  pertains  specifically  to  the 
storage  objects  within  a  computer  system  and  is  used  to  ensure  the 
secrecy  of  information  once  a  portion  of  memory  or  storage  space 
has  been  reallocated.   Specifically,  the  TNI  states: 

All  authorizations  to  the  information  contained  within  a 
storage  object  shall  be  revoked  prior  to  initial 
assignment,  allocation,  or  reallocation  to  a  subject  from 
the  TCB's  pool  of  unused  storage  objects.  No 
information,  including  encrypted  representations  of 
information,  produced  by  a  prior  subject's  actions  is  to 
be  available  to  any  subject  that  obtains  access  to  an 
object  that  has  been  released  back  to  the  system.  [Ref . 
15:  p.  20] 

As  applied  to  a  networked  environment,  the  object  reuse  criterion 
requires  the  NTCB  to  ensure  a  storage  object  does  not  contain 
information  for  which  the  subject  is  not  authorized  access  before 
granting  the  subject  access  rights.  This  requirement  must  be 
enforced  by  every  portion  of  the  network  that  contains  storage 
objects . 

Windows  NT  Features :  "All  resources,  including  executive  and 
non-executive  objects,  visible  at  the  TCB  interface  are 
appropriately  handled  with  respect  to  object  reuse."  [Ref.  21:  p. 
180]  The  object  reuse  requirements  are  fulfilled  by  the  executive 
or  non-executive  subsystem  which  is  responsible  for  creating  and 
maintaining  the  object.  Reuse  protection  is  provided  in  three 
ways:   [Ref.  21:  p.  153] 

•  All  fields  in  the  object's  header  and  body  are  initialized 
to  new  values  as  appropriate . 
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•  The  memory  allocated  for  an  object  is  written  over  with 
zeros . 

•  Only  the  data  that  has  been  written  most  recently  may  be 
read  and  nothing  more . 

For  objects  such  as  files  which  may  require  frequent  changes, 
access  controls  in  addition  to  the  DACL  are  provided  by  the  use  of 
high  water  marks  and  end-of-file  markers.  The  high  water  mark 
indicates  the  largest  size  of  the  file  prior  to  current  access. 
When  a  new  process  accesses  the  file,  the  subject  may  enlarge  the 
file,  moving  the  end-of-file  marker.  When  this  occurs,  the  file 
system  immediately  zeros  the  space  on  the  disk  or  tape  between  the 
old  high  water  mark  and  the  new  end-of-file  marker,  thus 
prohibiting  any  process  from  reading  beyond  the  previous  end-of- 
file  marker.  [Ref .  21]  The  same  process  is  used  for  any  object 
which  requires  frequent  backups  to  disk  in  order  to  minimize  the 
amount  of  dynamic  memory  required. 

Hardware  reuse  is  controlled  by  the  executive  subsystems, 
WinLogon,  or  Win32  and  includes  the  use  of  integer  and  floating 
point  registers,  VGA  memory,  and  special  purpose  registers.  The 
reuse  requirements  are  met  by  clearing  all  storage  locations  when 
one  interactive  user  logs  out  of  the  system  or  upon  reallocation  of 
the  storage.   Specifically: 

•  Processor  registers  are  initialized  to  a  known  state  when  a 
thread  is  started.  When  the  context  changes,  the  processor 
state  is  saved  and  all  registers  (except  floating  point)  are 
reinitialized.  Floating  point  registers  are  saved  and 
reinitialized  when  a  floating  point  instruction  is  issued  by 
a  new  context . 
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•  VGA  memory  is  cleared  and  can  no  longer  be  displayed  when  an 
interactive  user  logs  off . 

•  I/O  hardware   (e.g.,  drive  controller  status  registers, 
keyboard  buffers,  and  data  caches)  require  administrative  or 
system  privileges  to  access.   Any  attempt  to  access  these 
objects  by  an  unauthorized  subject  will  result  in  a  general 
exception  and  access  is  denied. 

•  Printer  buffers  are  cleared  by  printer  language  code  which 
is  sent  to  the  printer  prior  to  each  print  job. 

2.    Accountability 

a.    Identification  and  Authentication 

Requirement:  All  users  must  identify  themselves  to  the  TCB 
before  it  can  be  expected  to  mediate  any  actions  on  their  behalf. 
A  protected  mechanism  such  as  a  password  must  be  used  to 
authenticate  the  user's  identity,  and  all  authentication  data  must 
be  protected  from  unauthorized  disclosure.  The  TCB  must  be  able  to 
enforce  accountability  with  the  granularity  of  an  individual  user 
through  unique  identification  of  all  users  and  auditing  of  user 
actions . 

In  a  networked  environment,  the  identification  and 
authentication  may  be  performed  by  either  the  individual  component 
to  which  the  user  is  connected  or  some  other  component . 
Authentication  information  may  be  passed  between  components  of  the 
network  (NTCB  partitions)  without  reauthentication,  provided  the 
data  is  protected  from  unauthorized  disclosure  or  modification. 
Most  networked  environments  use  a  network  interface  card  (e.g., 
Ethernet  card)  in  the  computer  systems  for  authentication. 

Windows    NT    Features:        To  logon  to  the  system,  Windows  NT 
requires  every  user  to  be  identified  with  a  unique  username .   The 
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username  is  represented  internally  by  a  Security  Identifier  (SID) 
which  cannot  be  reassigned  to  another  user.    When  the  user 
initiates  a  process,  his  or  her  SID  is  incorporated  in  the  process' 
primary  token  and  is  used  for  auditing  of  all  security  related 
events . 

Windows  NT  permits  passwords  to  be  used  in  conjunction  with 
the  username.  The  passwords  are  encrypted  and  stored  in  the 
Security  Accounts  Manager  (SAM)  .  When  a  user  logs  onto  the  system, 
the  Local  Security  Authority  (LSA)  checks  with  the  SAM  to  ensure 
the  username  and  password  provided  are  authentic  before  granting 
the  user  access  to  the  system. 

There  are  some  serious  concerns  with  respect  to  identification 
and  authentication  in  a  networked  Windows  NT  environment.  First, 
the  Windows  NT  configuration  evaluated  by  the  NCSC  did  not  use  a 
secure  network  interface  card  to  ensure  authentication.  Second,  a 
remote  utility  permits  administrators  to  manage  all  network  users 
from  anywhere  on  the  network  provided  the  appropriate  trust 
relationships  have  been  established  between  users  and  groups  of 
users.  Should  the  administrator's  logon  identification  and 
password  be  compromised,  the  remote  utility  could  be  used  by  a 
"masquerader"  with  full  access  to  the  network  through  the  remote 
utility.  In  general,  Windows  NT  server  does  not  provide  any 
protection  against  intruders  beyond  the  password. 
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b.         Audit 

Requirement :  An  audit  trail  of  access  to  objects  protected  by 
the  TCB  must  be  provided.  The  specific  auditing  requirements 
outlined  in  the  TCSEC  are: 

The  TCB  shall  be  able  to  create,  maintain,  and  protect 
from  modification  or  unauthorized  access  or  destruction 
an  audit  trail  of  accesses  to  the  objects  it  protects. 
The  audit  data  shall  be  protected  by  the  TCB  so  that  read 
access  to  it  is  limited  to  those  who  are  authorized  for 
audit  data.  The  TCB  shall  be  able  to  record  the 
following  types  of  events:  use  of  identification  and 
authentication  mechanisms,  introduction  of  objects, 
actions  taken  by  computer  operators  and  system 
administrators  and/or  system  security  officers,  and  other 
security  relevant  events.  For  each  recorded  event,  the 
audit  record  shall  identify:  date  and  time  of  the  event, 
user,  type  of  event,  and  success  or  failure  of  the  event. 
For  identification/authentication  events  the  origin  of 
request  (e.g.,  terminal  ID)  shall  be  included  in  the 
audit  record.  For  events  that  introduce  an  object  into 
a  user's  address  space  and  for  object  deletion  events  the 
audit  record  shall  include  the  name  of  the  object.  The 
system  administrator  shall  be  able  to  selectively  audit 
the  actions  of  any  one  or  more  users  based  on  individual 
identity.   [Ref .  15:  p.  22] 

In  the  networked  environment,  the  auditing  capabilities  may  be 
provided  by  one  or  more  components  with  data  transmitted  to  a 
designated  collection  point.   Auditing  capabilities  are  to  be 
provided  for  both  local  and  remote  access;  and  provisions  must  be 
made  to  protect  the  data  from  loss  due  to  resource  inavailability . 

Windows  NT  Features:  The  Local  Security  Authority  (LSA) , 
Security  Reference  Monitor  (SRM) ,  protected  servers  and  executive 
subsystems,  Event  Logger,  and  Event  Viewer  combine  to  provide  the 
auditing  mechanism  for  Windows  NT.  The  LSA  defines  which  events 
are  to  be  audited  and  passes  the  appropriate  parameters  (i.e., 
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auditing  enabled  flag  and  event  categories)  to  the  SRM.  "The  event 
categories  are:  detailed  tracking,  system,  logon/logoff,  object 
access,  privilege  use,  policy  changes,  and  account  management." 
[Ref .  21:  p.  159]  The  event  types  included  in  each  event  category 
are  listed  in  Table  6  along  with  the  subsystem  which  is  responsible 
for  generating  the  audit  record. 

Audit  records  for  the  detailed  tracking,  system,  object 
access,  and  privilege  categories  are  constructed  by  the  SRM.  In 
order  for  an  audit  record  to  be  generated,  the  responsible 
subsystem  or  protected  server  must  send  a  request  to  the  SRM  that 
an  audit  record  be  made  for  each  occurrence  of  the  specified  event. 
Any  executive  subsystem  can  initiate  such  a  request,  but  user-mode 
protected  servers  must  have  the  Audit  privilege  before  making  the 
request.  The  Audit  privilege  is  identified  in  the  primary  token  of 
the  process  initiating  the  request. 

The  actual  audit  records  are  written  to  a  log  file  by  the 
Event  Logger.  In  turn,  the  system  administrator  may  read  the 
security  log  or  generate  a  report  by  using  the  Event  Viewer.  A 
user  must  have  either  the  Security  privilege  or  be  granted  access 
to  the  security  log  through  its  DACL  in  order  to  use  the  Event 
Viewer  to  view  the  file.  Read  and  write  permission  provided  by  the 
DACL  is  limited  to  members  of  the  Administrative  group  only,  and 
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Category 

Event  Type 

Constructor 

System 

System  Restart 

SRM 

System  Shutdown 

SRM 

Authentication  Package  Loaded 

LSA 

Registered  Logon  Process 

LSA 

AuditLog  Cleared 

SRM 

#Audits  Discarded  (due  to  full 
internal  queues) 

SRM 

Logon/ 
Logoff 

Logon  Successful 

LSA 

Unknown  User  or  Password 

LSA 

Time  Restricted  Logon  Failure 

LSA 

Account  Disabled 

LSA 

Account  Expired 

LSA 

Invalid  Workstation 

LSA 

Logon  Type  Restricted 

LSA 

Password  Expired 

LSA 

Failed  Logon 

LSA 

Logoff 

LSA 

Object 
Access 

Open  Object 

SRM 

Close  Handle 

SRM 

Privilege 
Use 

Assign  Special  Privilege 

SRM 

Privileged  Service 

SRM 

Privileged  Object  Access 

SRM 

Detailed 
Tracking 

Process  Created 

SRM 

Process  Exit 

SRM 

Duplicate  Handle 

SRM 

Indirect  Reference 

SRM 

Policy 
Changes 

Privilege  Assigned 

LSA 

Privilege  Removed 

LSA 

Audit  Policy  Change 

LSA 
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Category 

Event  Type 

Constructor 

Account 
Management 

Domain  Changed 

LSA 

User  Changed 

LSA 

User  Created 

LSA 

User  Deleted 

LSA 

Global  Group  Member  Removed 

LSA 

Global  Group  Member  Added 

LSA 

Local  Group  Changed 

LSA 

Local  Group  Created 

LSA 

Local  Group  Member  Removed 

LSA 

Local  Group  Member  Added 

LSA 

Local  Group  Deleted 

LSA 

Table  6.   Audit  Event  Types  [Ref .  21:  p.  160] 


the  Security  privilege  is  only  assigned  to  administrators.   Each 
audit  record  contains  the  following  information: 

•  Time  event  was  generated 

•  SID  of  the  process  generating  the  event 

•  Name  of  component  or  module  submitting  the  event 

•  Event  ID 

•  Type  of  event:    error,   warning,   success,   information, 
success  audit,  failure  audit. 

•  Event  category 

•  Computer 
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Figure  4  details  the  flow  and  interaction  of  the  auditing  scheme 
provided  by  Windows  NT. 
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Figure  4.   Windows  NT  Audit  Flow  [Ref .  21:  p.  158] 


There  are  three  situations  which  may  cause  audit  records  to  be 
lost : 

•  The  SRM  internal  queues  reach  their  high  water  mark. 

•  The  security  log  file  becomes  full . 

•  The  LSA  internal  queues  become  full. 

The  system  can  be  configured  to  prevent  a  loss  of  records  in  these 
instances.  Specifically,  the  wrap  around  option  for  the  security 
log  should  not  be  selected,  and  the  security  log  should  be  the 
maximum  size  available  with  a  registry  key  flagging  the  system  to 
halt  when  the  file  becomes  full.  These  options  are  set  by  the 
administrator  using  the  Event  Viewer. 
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Despite  the  security  features  of  Window  NT,  there  is  one 
vulnerability  which  can  permit  the  features  to  be  bypassed.  This 
was  demonstrated  in  the  spring  of  1995  and  reported  in  Government 
Computer  News  in  September.  Specifically,  the  article  by  Paul 
Constance  sites: 


According  to  DOD  security  criterion,  a  Class  C2  rating  is 
supposed  to  guarantee  that  an  operating  system  can 
prevent  unauthorized  access  to  specific  files  on  a 
computer  and  generate  an  unerasable  audit  trail  of 
attempts  to  gain  access .  But  at  the  Armed  Forces 
Communications  and  Electronic  Association's  TechNet 
conference  in  Washington  this  spring,  dozens  of  attendees 
watched  as  Robert  Wainright,  a  Camden,  N.J.,  computer 
security  consultant,  used  commercial  utilities  to  read, 
copy  and  delete  protected  data  on  the  hard  drive  of  a  PC 
running  Microsoft  Windows  NT  -  all  without  leaving  a 
trace . 


Wainright  exploited  the  so-called  "boot  floppy" 
vulnerability  of  PCs  with  Intel  Corp.  microprocessors  and 
floppy  disk  drives.  By  interrupting  a  normal  boot-up  from 
the  hard  drive,  a  user  can  invoke  the  system  setup 
routines  and  boot  from  the  floppy.  Using  assembly 
language  utilities,  an  intruder  then  can  read,  copy  or 
delete  files  from  the  hard  drive,  all  without  invoking 
the  OS  and  its  security  features.   [Ref .  24] 

The  reason  this  vulnerability  was  not  a  factor  in  the  evaluation 
conducted  by  the  NCSC  was  due  to  the  "fact  that  the  two  Proliant 
computers  from  Compaq  Computer  Corporation  on  which  Windows  NT  was 
evaluated  had  floppy  drives  that  were  disabled."  [Ref.  24] 
Typically,  NSA  will  refer  vulnerabilities  such  as  this  to  the  area 
of  "physical  security"  which  includes  measures  such  as  removing  the 
floppy  drive  every  night  or  installing  a  Fortezza  encryption  card 
to  increase  the  difficultly  for  an  intruder  attempting  to  boot  from 
the  floppy.    Ultimately,  the  responsibility  for  ensuring  this 
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vulnerability  is  not  taken  advantage  of  lies  with  the  system 
administrator  who  oversees  the  level  of  access  granted  to  system 
users.  In  a  networked  environment,  the  importance  of  this 
vulnerability  is  drastically  intensified  with  the  network  points  of 
access  distributed  throughout  buildings  and  across  campus  and 
should  not  be  ignored. 

3 .    Assurance 

a.    Operational  Assurance 

Requirement:  The  System  Architecture  shall  be  designed  to 
protect  the  TCB  from  external  interference  or  tampering.  Protected 
resources  (e.g.,  subjects  and  objects)  shall  be  isolated  in  a 
manner  which  enforces  access  control  and  auditing  requirements.  In 
a  networked  environment  which  partitions  the  NTCB,  each  partition 
will  provide  protection  over  the  resources  within  its  domain. 

System  integrity  is  achieved  through  hardware  and  software 
features  which  may  be  periodically  used  to  ensure  the  correct 
operation  of  the  hardware  and  firmware  elements  of  the  TCB. 
Features  must  also  be  available  for  validating  the  correct 
operation  of  a  new  component  before  it  is  added  to  the  network 
configuration.  If  a  failure  is  detected,  it  must  be  reported  to 
the  network  administrator  for  further  investigation. 

Windows  NT  Features :  Several  execution  domains  within  the  TCB 
are  used  to  provide  protection  from  external  interference  and 
tampering.  The  executive  is  protected  by  running  in  the  hardware 
kernel -mode  (i.e.,  privileged  mode),  and  the  protected  servers  and 
Administrator  tools  are  all  executed  through  a  TCB  process.   The 
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TCB  processes  are  "protected  through  the  address  space  isolation 
mechanisms  of  the  executive."  [Ref .  21:  p.  183]  Finally,  on-disk 
storage  and  data  structures  are  protected  through  the  use  of  the 
DACL  mechanism.  Through  these  features  and  the  audit  and  control 
mechanisms,  Windows  NT  protects  all  system  resources. 

For  the  system  integrity  requirements,  Microsoft  has  several 
packages  which  may  be  requested  for  system  testing  and  hardware 
validation  on  various  platforms.  For  example,  a  processor 
diagnostic  kit  is  available  for  Pentium  processors  as  well  as 
hardware  compatibility  test  suite  for  the  system  and  peripherals. 
In  addition,  most  computer  manufacturers  can  provide  a  suite  of 
diagnostic  tests  which  demonstrate  that  the  hardware  is  performing 
properly.  These  diagnostics  should  be  run  prior  to  loading  Windows 
NT  on  the  computer  and  revised  periodically  throughout  the  life  of 
the  system  to  ensure  the  hardware   is  performing  correctly. 

Jb.    Life-Cycle  Assurance 

Requirement :  Security  testing  must  be  performed  to  ensure  the 
security  mechanisms  act  in  the  manner  described  in  the  system 
documentation.  In  particular,  testing  should  focus  on  the 
potential  for  an  unauthorized  user  to  bypass  or  defeat  a  security 
mechanism  and  search  for  flaws  which  would  permit  unauthorized 
access  to  audit  or  authentication  data. 

Windows  NT  Features:  The  testing  performed  by  Microsoft  on 
Windows  NT  treated  each  component  as  a  separate  "black  box"  and 
focused  on  three  distinct  aspects:  [Ref.  21] 
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•  Testing  the  security- relevant  functionality  of  the  protected 
servers,  the  executive,  and  the  various  Application 
Programming  Interfaces  (APIs) . 

•  Testing  major  security- relevant  mechanisms  including  object 
access  protection,  object  reuse,  and  the  use  of  privileges. 

•  Testing  all  security-relevant  access  to  the  TCB  from  the 
administrative  tools  user  interface. 


Both  automatic  and  manual  tests  were  conducted  on  both  Windows  NT 
Server  and  NT  Workstation.  "In  general,  the  security-relevant  APIs 
of  the  protected  servers  and  the  executive  were  tested 
automatically  by  programs  that  exercised  numerous  calls  to  the 
APIs,  each  with  different  arguments  or  different  test 
configurations."   [Ref .  21:  p.  169] 

4 .    Documentation 

a.    Security  Features   User's  Guide 

Requirement :  The  manufacturer  must  provide  user  documentation 
which  describes  the  protection  mechanisms  provided  by  the  TCB, 
interprets  their  use,  and  describes  how  the  subsystems  or 
components  interact  with  one  another. 

Windows  NT  Features :      The  Windows  NT  Security  Features   Users 
Guide    (SFUG)    provides  the  following  information: 

•  Description  of  the  Windows  NT  TCB  and  its  protection 
mechanisms . 

•  "How  to"  information  concerning  logging  onto  Windows  NT, 
changing  user's  passwords,  locking  and  unlocking  the 
computer,  and  using  a  screen  saver. 

•  Explains  how  to  place  a  DACL  on  a  file  or  directory  and 
describes  what  ownership  means . 
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b.  Trusted  Facility  Manual 

Requirement:  This  manual   is   addressed  to   the   system 

administrator  and  identifies  functions  and  privileges  which  should 
be  controlled.   Information  concerning  the  review  and  maintenance 
of  audit   files   in  particular,   is  addressed.    In  addition, 
procedures  for  assisting  with  configuration  management  (including 
physical  and  administrative  controls)  must  be  provided. 

Windows  NT  Features :  The  Windows  NT  Trusted  Facility  Manual 
fulfills  these  requirements  by  describing  "privileged  built-in 
groups  whose  membership  should  be  controlled"  and  identifying  the 
privileges  and  special  abilities  they  provide.  [Ref .  21:  p.  185] 
Auditing  capabilities  are  also  described  in  detail  and  the  record 
structure  for  every  type  of  audit  event  is  provided.  Finally,  the 
various  administrative  tools  are  presented  and  discussed. 

c.  Test  Documentation 

Requirement:  This  documents  the  overall  testing  process  by 
identifying  the  test  plan,  describing  procedures  for  testing 
security  mechanisms,  and  furnishing  the  results  of  functional 
testing. 

Windows  NT  Features :  Following  the  security  testing  conducted 
by  Microsoft,  the  appropriate  test  documentation  was  created  and 
supplied  to  the  NCSC  during  the  product  evaluation.  The 
documentation  described  the  tests  conducted,  the  security 
mechanisms,  and  the  administrative  tools.  In  addition,  an  overview 
document  was  provided  which  detailed  the  purpose  and  goal  of  each 
test  suite.   Overall,  the  test  documentation  supplied  to  the  NCSC 
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was  determined  to  be  sufficient  "with  respect  to  both  breadth  and 
depth  of  coverage."   [Ref .  21:  p.  185] 

d.        Design  Documentation 

Requirement:  The   design   documentation   describes   the 

manufacturer's  security  philosophy  and  explains  how  it  is 
translated  into  the  TCB.  When  the  TCB  consist  of  distinct  modules, 
the  interfaces  between  the  modules  are  also  described.  For  a 
network  environment  with  a  partitioned  NTCB,  the  security  policy 
and  partitioning  of  the  NTCB  are  described  as  well  as  the 
allocation  of  security  requirements  among  components.  All  relevant 
components  and  their  method  of  interconnection  must  be  documented 
and  evaluated  in  order  for  the  security  of  the  entire  network  to  be 
validated.  The  Network  Security  Architecture  and  Design  is  the 
document  which  normally  details  the  specifics  concerning  the 
interface  between  components  of  the  network. 

Windows  NT  Features:  There  are  numerous  documents  and  texts 
available  covering  almost  every  aspect  of  Windows  NT.  Overall,  the 
system  is  very  well  documented.  Both  the  Windows  NT  3  . 5  Guidelines 
for  Security,  Audit,  and  Control  and  the  Windows  NT  Resource  Kit 
provide  great  detail  with  respect  to  security  features  and 
mechanisms.  However,  despite  a  thorough  review  by  the  NCSC  of  the 
documentation  provided  on  Windows  NT,  a  review  of  the  Network 
Security  Architecture  and  Design  was  not  conducted.  Therefore, 
assurance  regarding  the  network  design  has  not  been  provided  by 
NCSC. 
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5.    Additional  TCSEC  Features 

In  addition  to  the  Class  C2  level  requirements,  Windows  NT 
also  met  two  B2  level  requirements  in  the  testing  conducted  by  the 
NCSC.  Specifically,  the  NT  platform  was  evaluated  against  the  B2 
Trusted  Facility  Management  and  B2  Trusted  Path  functional 
requirements . 

For  the  B2  Trusted  Facility  Management  requirement,  the  TCB 
must  separate  operator  and  administrator  functions .  This  was  met 
by  the  software's  ability  to  grant  an  arbitrary  subset  of  rights  to 
a  user,  enabling  the  role  of  "operator"  to  be  defined  according  to 
local  requirements.  "In  addition,  built-in  groups,  like  Backup 
Operator  and  Power  Users  allow  users  to  perform  well-defined  roles 
without  providing  the  full  range  of  capabilities  associated  with 
administrator  accounts."  [Ref .  21:  p.  187]  This  follows  the 
popular  principle  of  "least  privilege"  which  was  introduced  by 
Jerome  Saltzer  and  Michael  Schroeder  in  their  paper  "The  Protection 
of  Information  in  Computer  Systems."   [Ref.  25] 

For  the  B2  Trusted  Path  requirement,  a  trusted  communication 
path  between  the  TCB  and  the  user  must  be  supported  for  initial 
logon  and  authentication,  with  communication  initiated  strictly  by 
the  user.  Windows  NT  provides  a  trusted  path  and  uses  the  Secure 
Attention  Sequence  (Ctrl,  Alt,  Del  keys  pressed  simultaneously)  to 
initiate  the  logon  and  authentication  process  by  the  user.  In 
turn,  this  sequence  guarantees  the  communication  will  be  with  the 
WinLogon  server  and  not  another  process.  Therefore,  control 
through  the  trusted  path  is  provided  for  the  user  to  logon,  logoff, 
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shutdown  the  system,   lock  the  workstation,   or  change  their 
password. 

Although  Windows  NT  meets  the  B2  level  requirements  for  the 
Trusted  Facility  Management  and  Trusted  Path,  it  was  not  evaluated 
against  any  assurance  requirements  above  the  Class  C2  level. 
Therefore,  the  overall  evaluation  rating  remained  at  Class  C2 . 

6 .    Other  Security  Services 

Part  II  of  the  TNI  describes  the  other  security  services  which 
are  relevant  to  a  networked  environment.  The  following  sections 
provide  an  individual  analysis  of  the  Falcon  LAN  as  compared  to 
each  of  these  services.  As  discussed  in  chapter  5,  each  service  is 
rated  according  to  its  functionality,  strength  of  mechanism,  and 
assurance.  The  ratings  assigned  to  the  Falcon  LAN  for  each  service 
are  based  upon  the  research  conducted  in  support  of  this  thesis. 

The  following  sections  describe  the  functionality  and  strength 
of  mechanism  requirements  for  each  service  and  applies  these 
requirements  to  the  Falcon  LAN.  The  assurance  provided  for  each 
mechanism  is  concerned  with  the  level  of  confidence  the  service 
provides  in  meeting  any  threat  to  the  mechanism.  This  is 
determined  by  ensuring  the  mechanism  has  been  implemented  correctly 
and  the  objectives  of  the  service  have  been  achieved.  The 
assurance  for  every  service  is  evaluated  with  a  rating  in  the  range 
of  none  to  good. 

a.    Communications   Integrity 

Communications  integrity  refers  to  several  security  services 
which  are   concerned  with  the   "accuracy,   faithfulness,   non- 
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corruptibility,  and  believability"  of  information  that  is 
transferred  between  components  of  a  computer  or  communications 
network.  [Ref .  15:  p.  178]  The  measures  used  to  achieve 
communications  integrity  have  some  strong  similarities  to  the 
mechanisms  used  to  enforce  DAC  and  MAC  requirements.  In  the 
networked  environment,  the  communications  integrity  concerns  are 
defined  through  three  aspects:  authentication,  communications 
field  integrity,  and  non- repudiation. 

(1)  Authentication.  The  functionality  criterion 
for  authentication  requires  the  network  to  ensure  all  exchanges  of 
data  are  established  with  the  addressed  component  and  not  with 
someone  attempting  to  masquerade  as  another  user  or  replay  a 
previous  transmission.  Authentication  typically  follows 
identification  and  the  system  must  protect  all  identification, 
authentication,  and  authorization  information.  Techniques 
routinely  applied  to  networks  to  achieve  authentication  include: 
passwords,  encryption,  and  mechanisms  which  use  the  characteristics 
and/or  possession  of  the  network  component  or  user. 

Encipherment  or  signature  mechanisms  may  be  used  to 
provide  the  authentication  service  through  encryption.  With  a 
conventional  private -key  encryption  system,  the  encryption  of  a 
message  with  a  private  key  automatically  implies  the  authenticity 
of  the  data's  origin  since  only  the  key's  holder  could  have 
produced  the  encrypted  message.  In  cases  where  dishonesty  may  lead 
to  a  dispute  over  the  transmission  of  an  encrypted  message,  a 
digital  signature  scheme  may  be  required  for  authentication.   If  a 

102 


public-key  encryption  scheme  is  used,  an  encrypted  message  is 
authenticated  by  decrypting  it  with  the  public  key  of  the  sender, 
thus  providing  proof  of  its  origin.  The  functionality  of  the 
authentication  service  provided  in  the  network  is  evaluated  as  none 
or  present,  according  to  the  presence  or  absence  of  the  service. 

The  strength  of  the  authentication  service  or 
mechanism  is  typically  evaluated  in  the  range  of  none  to  good.  If 
the  service  provided  is  through  the  use  of  passwords,  the  strength 
of  the  mechanism  is  dependent  upon  the  manner  in  which  passwords 
are  selected  and  protected.  Parameters  such  as  the  length  of  the 
password,  its  composition,  the  lifetime  permitted,  and  the 
protection  afforded  to  passwords  must  be  considered.  For  a 
password  mechanism  to  receive  an  evaluation  of  good,  it  must 
conform  to  the  Department  of  Defense  Password  Management  Guidance 
[Ref.  26],  of  12  April  1985. 

If  the  authentication  service  is  provided  through 
encryption,  the  mechanism  may  be  combined  with  handshaking 
protocols  or  non- repudiation  services  (e.g.,  notarization  scheme) 
to  strengthen  the  service.  The  overall  strength  of  the  service  is 
determined  by  evaluating  the  strength  of  the  ciphers,  the 
correctness  of  protocol  logic,  and  the  implementation. 

The  Falcon  LAN  uses  passwords  and  the  Windows  NT  TCB 
to  identify  and  authenticate  a  user  prior  to  granting  access  to  the 
system.  With  Windows  NT,  a  unique  Security  Identifier  (SID)  is 
used  to  identify  every  authorized  user.  The  SID  is  actually 
several  concatenated  numerical  values  which  are  hierarchical  in 
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nature  and  of  variable  length.    The  SAM  stores  the  username, 
corresponding  SID,  and  encrypted  password  in  a  Registry  which  is 
protected  by  a  DACL.   The  actual  authentication  procedure  with 
respect  to  password  management  was  described  in  the  NCSC  Final 
Evaluation  Report  as  follows: 

Of  particular  interest  is  the  storage  of  account 
passwords.  The  User  Manager  uses  a  one-way  function  to 
hash  the  password  and  then  temporarily  encrypts  the 
hashed  password,  using  a  trivial  session  key,  for 
transmission  to  the  SAM.  When  the  SAM  receives  the 
password,  it  decrypts  it,  again  using  the  trivial  session 
key,  and  re-encrypts  it  using  a  private  key  for  storage 
in  the  user's  account  in  the  security  accounts  database. 
The  private  key  that  the  SAM  uses  is  based  on  the 
account's  user  SID. 

The  main  role  of  the  SAM  during  the  authentication 
process  is  to  provide  requested  information  to  the  LSA 
and  the  authentication  package.  Again,  of  particular 
interest  is  the  user's  password.  When  the  password  is 
requested  from  the  SAM,  the  SAM  first  decrypts  the 
password,  using  its  private  key,  and  returns  the  hashed 
value.  Thus,  the  authentication  package  is  comparing  two 
hashed  values,  rather  than  clear  text  or  encrypted 
values.   [Ref.  21:  pp.  113  and  115] 

Windows  NT  provides  the  system  administrator  with 
much  flexibility  for  the  management  of  passwords.  Specifically, 
the  administrator  can  invoke  the  following  constraints  for  each 
system  user: 

•  Set  the  minimum  password  length 

•  Set  an  expiration  date  for  the  password 

•  Maintain  a  history  of  previously  used  passwords 

•  Create  a  dictionary  for  screening  proposed  passwords 

The  SAM  manages  these  constraints  for  each  user. 
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The  Falcon  LAN  does  not  have  any  other  hardware  or 
software  features  beyond  the  passwords  for  authentication  purposes. 
The  establishment  of  a  trusted  path  is  critical  to  authentication 
in  a  networked  environment.  Although  Windows  NT  was  evaluated  as 
meeting  the  Class  B2  trusted  path  functional  requirements  by  the 
NCSC,  the  trusted  path  does  not  exist  external  to  the  individual 
workstation.  Therefore,  assurance  from  the  path  between  nodes 
cannot  be  provided.  Based  upon  the  password  policy  enforced,  the 
capabilities  provided  by  Windows  NT,  and  the  lack  of  a  trusted  path 
for  the  overall  network,  the  estimated  authentication  ratings  for 
the  Falcon  LAN  are  provided  in  Table  7. 


Feature 

Rating 

Comments 

Functionality 

Present 

Strength  of 
Mechanism 

Fair 

A  trusted  path  for  the  overall 
network  would  significantly 
strengthen  the  authentication 
services.   As  for  passwords,  the 
only  Guidance  recommendation  not 
met  is  that  passwords  are  provided 
by  the  system  users  and  not 
automated. 

Assurance 

Fair 

Hardware  authentication  devices 
such  as  Fortezza  cards  would 
increase  the  level  of  assurance 
provided . 

Table  7.   Authentication  Ratings 


(2)  Communications  Field  Integrity.  Protection 
from  unauthorized  modification  of  any  of  the  fields  involved  in  a 
communication  is  referred  to  as  communications  field  integrity. 
The  header  or  protocol -information  field  and  the  user-data  field 
are  the  two  fields  most  commonly  referred  to  with  respect  to  data 
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communications.   In  addition  to  these  two,  other  fields  may  be 
identified  such  as  control  and  priority  fields. 

The  mechanism  used  to  ensure  communication  field 
integrity  counters  active  threats  and  protects  the  data  from 
unauthorized  modification.  Functionally,  the  service  should  ensure 
the  accuracy  of  the  data  transmitted  from  its  source  to  its 
destination  despite  possible  equipment  failure,  attempted  access  by 
an  unauthorized  user,  or  code  and  format  conversions  from 
communication  protocols.  An  automated  capability  to  test  for, 
detect,  and  report  errors  should  be  included  as  part  of  the 
network.  In  addition,  effective  countermeasures  to  address 
possible  attacks  to  the  communications  (e.g.,  jamming,  line  or  node 
outages,  active  wiretapping)  should  be  included.  These 
countermeasures  may  be  in  the  form  of  security  policy  and 
procedures,  physical  controls,  mechanisms,  or  protocols. 

The  functionality  of  the  field  integrity  service  is 
determined  through  an  evaluation  of  its  ability  to  detect  integrity 
violations.  The  functionality  rating  ranges  from  none  to  good. 
Table  8  details  the  specific  requirements  for  each  rating  level . 
For  ratings  of  minimum  and  fair,  either  requirement  must  be 
provided.  Each  rating  builds  on  the  previous  rating  and  for 
ratings  of  fair  and  good,  the  requirements  of  minimum  and  fair  must 
also  be  met,  respectively. 
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Rating 

Required  Features 

Minimum 

Integrity  is  provided  for  a  single  Protocol -Data- 
Unit  (PDU)  (e.g.,  packet,  datagram)  through  the 
ability  to  determine  if  a  received  PDU  has  been 
modified. 

It  can  be  determined  if  selected  fields  within  a 
PDU  have  been  modified. 

Fair 

It  can  be  determined  if  selected  fields  transferred 
over  a  connection  have  been  modified,  inserted, 
deleted,  or  replayed. 

Any  modification,  insertion,  deletion,  or  replay  of 
a  PDU  within  a  PDU  sequence  can  be  detected  with  no 
recovery  attempted. 

Good 

Any  modification,  insertion,  deletion,  or  replay  of 
a  PDU  within  a  PDU  sequence  can  be  detected  with 
recovery  attempted. 

Table  8 .   Basis  for  Communications  Field  Integrity 
Functionality  Rating  [Ref .  15:  p.  181] 


The  strength  of  the  mechanism  is  determined  through 
the  policy,  procedures,  automated  or  physical  controls,  mechanisms, 
and  protocols  which  ensure  the  data  has  not  been  subjected  to 
excessive  random  errors  and  unauthorized  modification.  Any 
countermeasures  to  prevent  message  stream  modifications  should  be 
identified  and  proven  to  be  effective.  In  addition,  the 
probability  of  an  undetected  error  should  also  be  identified.  An 
automated  capability  for  testing,  detecting,  reporting,  and/or 
recovering  from  communication  errors  or  corruption  should  be 
incorporated  into  the  network.  The  evaluation  range  used  for  the 
strength  of  the  mechanism  is  from  none  to  good. 

The  Falcon  LAN  is  an  Ethernet  10Base2  network. 
Therefore,  the  hardware  has  the  collision  detection  features  of 
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Ethernet  (i.e.,  if  a  collision  is  detected  during  transmission,  a 
special  jam  signal  is  transmitted  and  the  message  or  packet  is 
resent)  .  Physical  controls  have  also  been  implemented  for  the 
servers  and  fiber  transceivers  so  only  authorized  personnel  are 
granted  access  to  the  equipment.  In  addition,  use  of  the  TCP/IP 
protocol  provides  added  checks  to  the  transmission  of  packets. 
Beyond  these  controls,  no  other  security  features  are  currently  in 
place  which  would  relate  directly  to  the  communications  field 
integrity  service.  Although  the  equipment  does  test  and  correct 
transmission  collisions,  it  does  not  provide  the  capabilities 
described  for  a  minimum  functionality  rating  in  Table  9 . 
Therefore,  the  rating  for  the  communications  field  integrity  would 
have  to  be  none . 

(3)  Non-Repudiation.  The  non- repudiation  service 
"provides  unforgeable  proof  of  shipment  and/or  receipt  of  data." 
[Ref.  15:  p.  182]  This  is  accomplished  by  one  or  both  of  the 
following  means: 

•  Providing  the  recipient  of  the  data  with  a  proof  of  its 
origin  which  will  prohibit  the  sender  from  denying  its 
transmission  or  contents. 

•  Providing  the  sender  with  proof  a  delivery  so  the  recipient 
cannot  deny  receiving  the  transmission  or  its  contents. 

Digital  signature  techniques  are  the  most  widely 
used  form  of  non- repudiation  service  provided.  The  technique  used 
may  be  based  on  either  the  signature  of  the  parties  or  an 
arbitrated  scheme  in  which  a  third  party  validates  the  signature  in 


108 


the  same  manner  as  a  notary  public  certifies  the  signatures  on 
paper  documents.  The  functionality  of  such  a  scheme  is  rated  as 
either  none  or  present,  signifying  the  absence  or  presence  of  the 
service  on  the  network. 

The  strength  of  the  non- repudiation  service  is 
determined  by  the  trust  given  to  the  underlying  cryptography  used 
with  the  digital  signature,  the  correctness  of  the  protocol  logic, 
and  the  appropriateness  of  the  implementation.  The  evaluation 
range  used  for  describing  the  mechanism' s  strength  is  from  none  to 
good.  The  Falcon  LAN  does  not  currently  provide  any  mechanism  for 
this  service.   Therefore,  the  functionality  rating  would  be  none. 

b.        Denial   of  Service 

Service  is  denied  whenever  the  throughput  on  the  network 
falls  below  a  pre-established  threshold,  access  to  a  remote 
component  is  not  available,  or  resources  are  not  available  to  end 
users.  If  a  connection  is  active,  the  denial  of  service  condition 
may  be  detected  by  monitoring  the  maximum  waiting  time  or  examining 
the  level  of  throughput  on  the  system.  In  contrast,  when  a 
connection  is  not  currently  engaged,  there  is  no  way  of  determining 
a  denial  of  service  attack  which  cuts  off  the  flow  of  information 
unless  the  network  component  knows  explicitly  when  data  are  to  be 
transferred  to  it.  The  effects  of  the  denial  of  service  condition 
should  be  considered  for  all  network  components  when  determining 
network  service  requirements. 
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(1)  Continuity  of  Operations.  Security  features 
aimed  at  protecting  the  network  against  denial  of  service  attacks 
from  external  sources  may  include  built-in  redundancy  throughout 
the  network,  distribution  of  network  control  functions,  fault 
tolerance  mechanisms  to  prevent  hardware  failures,  and  security 
controls  to  monitor  access  and  prevent  wiretapping.  The 
functionality  of  the  continuity  service  is  evaluated  with  ratings 
ranging  from  none  to  good.  Table  9  identifies  the  basic 
requirements  for  the  various  ratings. 

The  strength  of  the  mechanism  is  also  rated  from 
none  to  good,  and  is  evaluated  according  to  the  robustness  of  the 
feature  and  its  operational  maintenance.  Attributes  such  as 
error/fault  detection,  fault  treatment,  damage  assessment, 
error/failure  recovery,  component /segment  crash  recovery,  and 
network  crash  recovery  may  be  examined  during  the  evaluation 
process . 


Rating 

Requirement 

Minimum 

The  service  should  detect  and  report  conditions 
which  result  in  a  degradation  of  service  below  a 
specified  minimum. 

Fair 

The  service  provided  for  the  minimum  rating  would 
continue  in  the  event  of  equipment  failure  or 
actions  by  unauthorized  users  or  processes.   This 
service  may  be  provided  from  system  redundancy,  an 
alternate  facility,  or  some  other  means. 

Good 

This  is  the  same  requirement  as  the  minimum  rating, 
but  with  automatic  adaptation. 

Table  9.   Functionality  Ratings  for  Continuity  of  Operations 
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Continuity  of  operations  features  are  incorporated 
on  the  Falcon  LAN  through  hardware,  software,  and  physical 
controls.  As  previously  described,  the  Ethernet  backbone  has 
collision  detection  and  recovery  features  built-in  which  monitor 
the  transmission  of  packets.  A  tape  backup  system  is  used  to 
backup  crucial  data  in  case  a  network  crash  should  occur.  A  full 
system  backup  is  performed  on  a  weekly  basis  and  incremental 
backups  (which  include  the  registry  files)  are  performed  daily. 
All  backup  tapes  are  kept  in  a  vault  in  a  different  building  than 
the  servers.  In  addition,  an  Uninterruptable  Power  Supply  (UPS) 
provides  added  assurance  in  the  event  of  a  loss  of  power. 

With  Windows  NT,  the  Redundant  Array  of  Inexpensive 
Drives  (RAID)  technology  has  been  used  to  establish  a  mirror  of  the 
server  files.  RAID  is  a  method  of  protecting  "data  by  combining 
smaller,  less  expensive  drives  together  in  a  way  that  data 
redundancy  and  security  is  increased."  [Ref .  27:  p.  125]  The 
Falcon  LAN  uses  RAID  level  five  which  uses  parity  bits  to 
reconstruct  damaged  data.  A  total  of  6  GBytes  of  data  are  mirrored 
between  two  of  the  servers . 

Finally,  physical  controls  imposed  on  the  location 
of  the  servers  protect  them  from  physical  access  by  unauthorized 
individuals,  and  cabling  is  visually  inspected  for  wiretapping.  In 
addition,  LED  indication  lights  on  the  hub  may  be  used  for 
monitoring  access  to  the  LAN. 

The  majority  of  these  features  are  aimed  at 
protecting  physical  assets  and  restoring  information  in  the  event 
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of  a  system  failure.  However,  the  Falcon  LAN  is  missing  mechanisms 
which  would  help  detect  and  report  conditions  resulting  in  a 
degradation  of  service.  For  example,  if  someone  were  to  flood  the 
network  with  packets,  there  is  no  mechanism  in  place  to  detect  the 
attack.  Or,  if  a  node  on  the  network  were  to  experience  a 
degradation  in  service,  there  is  no  mechanism  to  detect  the 
reduction.  Mechanisms  such  as  protocols  which  ping  network  nodes 
for  availability  would  further  strengthen  the  assurance  for 
continuity  of  operations  on  the  Falcon  LAN.  Balancing  the  lack  of 
detection  and  reporting  services  with  the  fault  tolerance  features 
provided,  the  ratings  for  continuity  of  operations  are  estimated  to 
be  minimum  for  all  three  features:  functionality,  strength  of 
mechanism,  and  assurance. 

(2)  Protocol  Based  Protection.  Denial  of  service 
mechanisms  are  often  protocol  based  and  can  involve  testing  or 
probing  the  network.  In  an  attempt  not  to  increase  network 
overhead,  existing  communications  availability  services  should  be 
used  whenever  feasible.  Typically,  the  rating  used  for  the 
functionality  of  this  service  is  based  upon  the  number  of  protocol 
based  mechanisms  provided.  Specifically,  one  mechanism  would 
equate  to  a  rating  of  minimum,  two  or  three  mechanisms  are 
considered  fair,  and  three  or  more  would  be  rated  as  good. 

The  strength  of  the  mechanism  is  normally  determined 
through  off-line  testing  and/or  simulation.  "Network  protocol 
robustness  may  decrease  inversely  with  network  loading"  and  the 
testing  should  address  this  possibility.  [Ref.  15:  p.  187]   In 
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addition,  the  evaluation  should  test  for  both  internal  failures  and 
external  attacks.  Upon  completion  of  all  testing,  the  mechanism  is 
assigned  a  rating  between  none  and  good  for  strength. 

Windows  NT  supports  numerous  transmission  protocols. 
As  a  default,  NT  uses  the  Network  Basic  Input/Output  System 
(NetBIOS)  Extended  User  Interface  (NetBEUI)  as  the  actual  transport 
protocol.  [Ref .  27:  p.  39]  NetBEUI  operates  at  the  session  layer 
of  the  Open  Systems  Interconnection  (OSI)  reference  model  and  is 
responsible  for  synchronizing  and  sequencing  the  packets  in  a 
network  connection,  ensuring  the  connection  is  maintained  until 
transmission  is  completed,  and  ensuring  appropriate  security 
measures  are  taken  during  the  session.  [Ref.  28:  p.  730] 

Windows  NT  also  supports  the  Transmission  Control 
Protocol/Internet  Protocol  (TCP/IP) ,  the  Data  Link  Control  (DLC) 
protocol,  and  the  Internetwork  Packet  Exchange /Sequenced  Packet 
Exchange  (IPX/SPX)  protocol.  DLC  is  typically  used  with  token  ring 
networks  to  handle  communications  between  microcomputers  and 
mainframes.  The  IPX/SPX  protocol  is  the  main  protocol  used  by 
Novell  and  provides  communication  between  Netware  products  and 
Windows  NT.  Finally,  TCP/IP  is  the  main  protocol  used  by  NT  to 
support  internetworking.  [Ref.  27:  pp.  39-40]  The  TCP/IP 
protocol  suite  is  a  "connection-  and  stream-oriented,  transport 
layer  protocol"  which  uses  the  IP  portion  at  the  network  layer  to 
actually  deliver  the  packets.  [Ref.  28:   p.  809] 

The  Falcon  LAN  uses  both  the  NetBEUI  and  TCP/IP 
protocols  for  transmission  with  Windows  NT.  However,  no  testing  or 
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simulation  has  been  conducted  with  these  protocols  to  fully 
determine  the  level  of  protection  provided  within  the  Falcon  LAN. 
Therefore,  ratings  for  protocol  based  protection  must  be  based  upon 
the  wide- spread  use  and  testing  of  these  protocols.  Overall,  the 
rating  is  estimated  to  be  fair  for  all  three:  functionality, 
strength  of  the  service,  and  assurance. 

(3)  Network  Management.  Network  management  focuses 
on  the  overall  health  of  the  network,  detecting  failures  and 
reduction  in  levels  of  service.  Any  network  management  protocols 
or  tools  should  detect  problems  in  these  areas  and  report  them  to 
the  system  administrator.  The  functionality  of  such  tools  are 
rated  as  either  none  or  present. 

"Integrity  and  adequacy  of  control  in  a  network  are 
the  keys  in  coping  with  denial  of  service  conditions."  [Ref.  15: 
p.  188]  Fault  tolerance  mechanisms  must  be  in  place  to  deal  with 
both  internal  failures  and  external  attacks .  The  strength  of  the 
mechanisms  provided  are  evaluated  and  assigned  a  rating  in  the 
range  of  none  to  good. 

The  Falcon  LAN  does  have  several  fault  tolerance 
mechanisms  in  place  to  guard  against  internal  failures.  (These 
were  described  previously  under  the  continuity  of  operations 
section.)  These  features  which  are  in  place  would  also  be  useful 
in  the  event  of  a  line  being  cut  or  a  segment  of  the  LAN  being 
taken  out  of  service.  Other  than  the  fault  tolerant  features  and 
a  staff  devoted  to  monitoring  the  daily  operation  of  the  LAN,  there 
are  no  other  tools  or  features  implemented.    In  addition,  as 
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previously  noted,  the  LAN  is  lacking  mechanisms  which  would  detect 
and  report  system  failures.  Overall,  the  functionality  rating  for 
the  LAN  would  be  present  and  the  strength  of  mechanism  and 
assurance  ratings  for  the  overall  services  provided  are  estimated 
to  be  fair.  If  other  tools  such  as  a  firewall  and  a 
detection/reporting  mechanism  were  added,  the  strength  and 
assurance  ratings  could  be  higher. 

c.    Compromise  Protection 

Compromise  protection  refers  to  security  services  which  are 
concerned  with  the  secrecy  and  non-disclosure  of  information 
between  components  on  the  network.  These  features  may  be  provided 
through  administrative,  technical,  or  physical  means. 

(1)  Data  Confidentiality.  Data  confidentiality 
guards  against  the  unauthorized  disclosure  of  information,  normally 
through  passive  wiretapping  or  an  unauthorized  release  of  a 
message.  Physical  protection  and  encryption  are  the  most  common 
forms  of  protection  used  in  networks.  The  functionality  of  this 
service  is  rated  as  none  or  present  to  indicate  the  absence  or 
existence  of  the  service  within  the  network. 

Through  physical  protection  and  encryption,  the 
release  of  a  message  and  traffic  analysis  can  be  prevented.  For 
encryption  mechanisms,  the  NSA  normally  evaluates  the  strength  of 
the  mechanism  for  a  given  environment  and  provides  the  sensitivity 
level  of  the  data  the  mechanism  is  approved  to  protect.  In  turn, 
the  sensitivity  level  is  used  as  the  evaluation  level  for  this 
service . 
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The  Falcon  LAN  does  not  currently  use  any  encryption 
packages  to  protect  data  that  is  transmitted.  Although  physical 
security  measures  have  been  taken  to  secure  the  servers  and 
transceivers,  each  workstation  on  the  network  provides  a  point  of 
access.  The  LAN  does  use  the  Windows  NT  time-out  feature,  which 
requires  a  password  be  provided  for  access  if  the  computer  has  been 
sitting  idle  for  a  period  of  time.  This  reduces  the  probability 
that  one  can  gain  access  to  a  computer  left  idle,  but  does  not 
eliminate  the  threat.  Since  the  network  administrator  and  his 
staff  cannot  possibly  be  everywhere  continuously  to  ensure 
personnel  are  logging  off  when  done  with  their  system  and 
unauthorized  users  are  not  attempting  to  use  workstations,  the  data 
confidentiality  service  must  be  rated  as  none. 

(2)  Traffic  Flow  Confidentiality.  This  aspect  of 
confidentiality  guards  against  the  unauthorized  disclosure  of 
information  through  traffic  analysis.  "Traffic  flow 
confidentiality  is  concerned  with  masking  the  frequency,  length, 
and  origin-destination  patterns  of  communications  between  protocol 
entities."  [Ref .  15:  p.  190]  Physical  protection,  encryption, 
and  traffic  padding  are  the  primary  mechanisms  used  to  guard 
against  the  traffic  analysis  threat.  The  functionality  of  the 
service  is  normally  rated  as  none  or  present,  and  the  strength  of 
the  mechanism  is  evaluated  in  the  same  manner  as  the  strength  of 
the  data  confidentiality  mechanism. 
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Again,  the  Falcon  LAN  does  not  have  any  mechanisms 
or  features  which  would  provide  this  service.  Therefore,  the 
rating  for  traffic  flow  confidentiality  is  also  none. 

(3)  Selective  Routing.  The  routes  over  which  data 
travel  in  a  network  can  be  selected  through  dynamic  routing  or 
prearranged  paths.  In  some  cases,  certain  paths  or  nodes  may  need 
to  be  avoided  when  persistent  attacks  occur  along  that  segment.  In 
addition,  data  carrying  certain  labels  may  need  to  be  prohibited 
from  traveling  over  certain  segments  of  the  network.  The  selective 
routing  feature  enables  these  changes  to  be  made  in  the  routing  of 
data  across  the  network.  Typically,  the  functionality  of  such  a 
service  is  rated  as  none  or  present  and  the  strength  of  the 
mechanism  is  given  a  rating  between  none  and  good.  The  Falcon  LAN 
does  not  have  this  capability  installed  so  the  rating  for  the 
selective  routing  service  would  be  none. 

d.    Summary  of  Falcon  LAN  Services 

Table  10  provides  a  rating  summary  of  the  services 
provided  by  the  Falcon  LAN.  Various  ratings  may  change  as  security 
features  are  added  to  the  network.  For  example,  if  encryption 
software  was  implemented  for  all  users,  the  ratings  for  non- 
repudiation,  traffic  flow  confidentiality,  and  compromise 
protection  could  change.  Since  the  network  has  not  fully  achieved 
the  desired  level  of  functionality,  each  of  these  services  should 
be  re-evaluated  once  all  changes  have  been  implemented. 
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Network  Security  Service 

Criterion 

Falcon  LAN 

Rating 

Communications  Integrity/ 
Authentication 

Functionality 

Strength 

Assurance 

Present 

Fair 

Fair 

Communications  Field 
Integrity 

Functionality 

None 

Non- Repudiation 

Functionality 

None 

Denial  of  Service/ 
Continuity  of  Operations 

Functionality 

Strength 

Assurance 

Minimum 
Minimum 
Minimum 

Protocol  Based  Protection 

Functionality 

Strength 

Assurance 

Fair 
Fair 
Fair 

Network  Management 

Functionality 

Strength 

Assurance 

Present 

Fair 

Fair 

Compromise  Protection/ 
Data  Confidentiality 

Functionality 

None 

Traffic  Flow 
Confidentiality 

Functionality 

None 

Selective  Routing 

Functionality 

None 

Table  10.   Evaluation  of  Network  Security  Services  for  Falcon  LAN 


F.    MEETING  INTEROPERABILITY  REQUIREMENTS 

Ralph  H.  Sprague,  Jr.  and  Barbara  McNurlin  define 
interoperability  in  their  book  Information  Systems  Management  in 
Practice  as  "the  capability  for  different  machines,  using  different 
operating  systems,  on  different  networks  to  work  together  on  tasks 
-  exchanging  information  in  standard  ways  without  any  changes  in 
the  command  language  or  in  functionality  and  without  physical 
intervention."  [Ref .  29:  p.  186]  Overall,  achieving 
interoperability  can  be  a  quite  cumbersome  task  and  typically  must 
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address  both  internal  and  external  issues.  Numerous  aspects  of  the 
systems  must  be  addressed,  including  policies,  hardware,  software, 
and  protocols.  Although  many  national  and  international  committees 
have  made  progress  over  the  years  in  developing  standards  aimed 
precisely  at  the  interoperability  issue,  the  end  of  the  road  has 
not  yet  been  reached.  In  an  era  of  piecemeal  systems,  a  great  deal 
of  intervention  is  required  to  achieve  total  connectivity. 

In  meeting  the  interoperability  requirements  of  the  Falcon 
LAN,  many  issues  needed  to  be  addressed.  As  is  typical  with  any 
LAN  installation,  the  various  functional  requirements  have  been 
prioritized  and  are  being  implemented  in  their  respective  order  of 
importance  to  the  command.  To  date,  not  all  requirements  have  been 
met.  The  following  sections  identify  the  interoperability  issues 
that  have  been  encountered  thus  far,  and  the  status  of  each 
functional  requirement. 

1.    Provide  a  Communications  System 

The  primary  goal  of  the  LAN  was  to  provide  a  backbone 
communication  system  for  the  various  NSGD  offices  located  in  two 
different  buildings.  This  was  accomplished  with  the  backbone 
installation  conducted  by  NISE  West  and  the  subsequent  computer 
installations  conducted  by  the  NSGD  staff. 

Since  the  software  applications  were  all  either  Windows  based 

(i.e.,  Microsoft)  or  Windows  compatible,  software  interoperability 

within  the  LAN  was  not  a  major  issue.  There  were,  however,  several 

problems  due  to  the  hardware  configurations  during  the  initial 

installation.   For  example,  a  CD-ROM  drive  was  required  for  the 
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installation  of  Windows  NT  on  the  server.  However,  the  CD-ROM 
drive  purchased  had  an  Integrated  Drive  Electronics  (IDE)  interface 
and  NT  requires  a  Small  Computer  Systems  Interface-II  (SCSI-II) . 
Once  a  different  CD-ROM  drive  was  purchased  and  installed,  it  was 
not  recognized  by  the  hardware  because  of  a  SCSI  adapter.  The 
motherboard  appeared  to  be  confused  between  that  and  the  SCSI 
adapter  on  the  hard  drive.  The  problem  was  solved  once  the  adapter 
was  removed  from  the  CD-ROM  drive.  Additional  problems  arose  from 
the  amount  of  time  (approximately  one  year)  the  hardware  sat  in 
storage  prior  to  installation.  For  example,  at  least  three  of  the 
ten  mice  did  not  work  with  the  first  set  of  computers  installed. 
Eventually,  the  hardware  problems  were  worked  out  and  the  staff  had 
it' s  LAN. 

2 .  Provide  a  Student  Tracking  System 

The  development  of  a  unified  database  for  tracking  student 
information  was  also  desired.  The  database  software  selected  for 
this  task  was  Microsoft's  Access  and  SQL  server.  Since  SQL  is  part 
of  the  Microsoft  Back  Office  suite,  interoperability  between  the 
database  software  and  the  network  operating  system  was  not  an 
issue.  The  actual  development  of  the  database  is  currently  in 
progress . 

3 .  Provide  for  Service  Management 

Access  was  needed  to  the  DLI  Student  Database,  NITRAS,  and  the 
Army  ATRRS  programs  to  allow  service  needs  and  student  eligibility 
requirements  to  be  met.  To  date,  access  to  the  DLI  database  has 
not  been  achieved  due  to  priorities  assigned  to  the  functional 
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requirements.   Access  to  both  NITRAS  and  ATRRS  is  being  handled 
through  dial-up  access  with  a  modem. 

4 .  Provide  for  Supply  and  Fiscal  Tracking 

Access  was  also  required  to  the  Naval  Postgraduate  School 
supply  system,  the  new  supply  and  purchasing  system,  and  on-line 
catalogs  and  supply  status  servers.  This  requirement  is  lower  on 
the  list  of  priorities  than  the  DLI  database.  Therefore,  it  has 
not  been  accomplished  to  date. 

5.  Provide  Career  Counseling  Assistance 

This  requirement  was  to  provide  for  the  maintenance  and  access 
to  the  student  database  with  career  counseling  information  such  as 
ASVAB  scores,  next  duty  assignment,  and  prospective  gains  and 
losses.  In  addition,  the  Educational  Services  Officer  requires 
access  to  course  completion,  PARS  and  other  advancement 
information,  and  the  staff  required  access  to  BUPER's  bulletin 
boards  and  detailer  E-mail. 

The  NSGD  student  database  is  currently  being  converted  to 
Microsoft  Access.  Once  the  conversion  is  completed,  it  will  then 
be  formatted  for  the  SQL  server.  Microsoft  Access  is  a  relational 
database  management  system  which  permits  data  to  be  viewed  in 
various  ways.  The  "Database  Wizard"  enables  users  to  build  tables, 
queries,  forms,  and  reports  from  the  data  and  the  "Table  Analyzer 
Wizard"  enables  data  from  flat-files  and  spreadsheets  to  be 
converted  into  a  relational  database.  [Ref.  30]  The  SQL  server 
provides  the  database  management  system  functions  needed  for  the 
distributed  client-server  environment. 
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The  detailer  electronic  mail  requirement  has  been  achieved  and 
is  working  smoothly.  Access  to  BUPERS  bulletin  board  is  provided 
through  two  means:  dial-up  modem  connectivity  and  the  BUPERS  World 
Wide  Web  (WWW)  home  page. 

6 .  Provide  for  Command  Information  Dissemination 

Dissemination  and  tracking  of  command  welcome  aboard  packages, 
and  access  to  NSGD  home  page  from  the  World  Wide  Web  (WWW)  was 
required.   These  requirements  have  all  been  accomplished  with  WWW 
access  provided  through  the  DLI  CISCO  router.   The  NSGD  home  page 
can  be  found  at  http://www.nsgdmry.navy.mil. 

7 .  Allow  for  the  Sharing  of  Electronic  mail  with  DLI 

Access  to  and  compatibility  with  the  DLI  Microsoft  Mail  server 
was  needed  to  allow  the  transfer  of  electronic  mail  between  the 
NSGD  and  DLI  staffs.  This  included  the  requirement  to  establish 
electronic  mail  accounts  for  the  NSGD  staff  and  students. 
Electronic  mail  within  the  NSGD  staff  has  been  accomplished, 
however,  connectivity  with  the  DLI  staff  has  not.  Problems  have 
been  encountered  due  to  the  differences  between  the  Microsoft  Mail 
Server  and  Microsoft  Exchange  Server  configurations.  DLI  will  be 
changing  from  the  Mail  Server  to  an  Exchange  Server  in  the  near 
future  which  should  permit  the  connectivity  to  proceed.  The 
fulfillment  of  this  requirement  remains  in  progress. 

8.  Provide  for  the  Instruction  of  the  Cryptologic 
Technician  Apprentice  Common  Core  Curriculum 

Connections  between  the  Falcon  LAN  and  the  new  educational  LAN 

in  the  Learning  Center  is  desired.   To  date,  this  requirement  has 
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not  been  fulfilled  due  to  priorities  and  the  need  for  hardware 
upgrades  to  complete  the  task.  The  hardware  required  for 
connecting  the  LANs  has  been  received,   just  not  installed. 

9 .    Provide  for  the  Dissemination  of  Message  Traffic  on  the 
LAN 

The  ability  to  receive  unclassified  message  traffic  using  the 

Defense  Message  System  (DMS)  was  an  additional  requirement  for  the 

Falcon  LAN.   This  is  currently  being  handled  through  a  stand-alone 

computer  and  was  the  focus  of  another  thesis. 
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VI.   CONCLUSION  -  THE  PRO'S  AND  CON'S  OF  ENSURING  TRUST 


The  art  of  war  teaches  us  to  rely  not  on  the  likelihood 
of  the  enemy's  not  coming,  but  on  our  own  readiness  to 
receive  him;  not  on  the  chance  of  his  not  attacking,  but 
rather  on  the  fact  that  we  have  made  our  position 
unassailable. 

-    The  Art  of  War 

Sun  Tzu   [Ref.  2:   p.  207] 

CONCLUSIONS 


Requirement 

Status 

Comments 

Discretionary- 
Access  Control 

Met 

Object  Reuse 

Met 

Identification 

and 

Authentication 

Not  Met 

Secure  network  interface  needed; 
remote  access  may  be  a  problem 

Audit 

Not  Met 

Boot  floppy  vulnerability;  Fortezza 
cards  may  take  care  of  this  problem 

Operational 
Assurance 

Met 

Life-Cycle 
Assurance 

Not  Met 

Testing  is  needed  for  a  networked 
environment . 

Security 
Features  User's 
Guide 

Met 

Trusted 
Facility  Manual 

Met 

Test 

Documentation 

Not  Met 

Documentation  based  on  a  networked 
environment  is  needed. 

Design 
Documentation 

Met 

The  Network  System  Architecture  and 
Design  need  a  thorough  evaluation. 
However,  this  is  listed  as  met 
because  Windows  NT  is  so  thoroughly 
documented . 

Table  11.   Analysis  of  Falcon  LAN  Class  C2  Requirements 
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With  the  current  configuration  of  the  Falcon  LAN,  the  system 
should  not  be  accredited  as  providing  a  Class  C2  level  of  trust. 
It  does  come  close  in  many  regards,  although  several  requirements 
are  met  only  in  Windows  NT  in  stand-alone  mode.  The  issue  of 
authentication  is  the  major  concern  which  needs  to  be  addressed. 
Table  11  provides  a  breakdown  of  the  TCSEC/TNI  requirements  for 
Class  C2  and  identifies  the  specific  points  of  concern  with  respect 
to  the  Falcon  LAN. 

B .    RECOMMENDATIONS 

After  thoroughly  evaluating  the  TCSEC  and  TNI  criterion,  there 
are  two  major  recommendations  for  the  Falcon  LAN.  First,  the 
addition  of  secure  network  interface  cards  or  Fortezza  cards  to  the 
various  components  of  the  network  may  help  to  eliminate  the 
authentication  problems  identified.  NSA  has  expressed  concern 
about  the  authentication  problems  of  Windows  NT  and  has  agreed  to 
pay  for  the  development  of  a  special  version  of  the  software  which 
meets  B-level  requirements.  Government  Computer  News  announced  in 
January  that  NSA  had  "awarded  a  contract  to  Global  Internet  of  Palo 
Alto,  California,  to  conduct  a  feasibility  study  on  ways  to  beef  up 
Windows  NT  3.51  security  and  develop  a  prototype  encryption  card 
access  control  system  based  on  Fortezza."  [Ref .  31]  If  this 
upgrade  does  not  come  in  time  for  meeting  the  Class  C2  requirement, 
then  depending  upon  the  results  of  the  current  testing  by  the  NCSC 
on  Novell's  Netware  version  4.1,  the  command  may  want  to 
investigate  replacing  the  network  operating  system  itself  (Windows 
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NT  Server)  with  Netware.  Windows  NT  Workstation  could  still  be 
maintained  on  the  various  components.  However,  prior  to  deciding 
on  this  course  of  action,  research  into  the  compatibility  of  the 
file  systems  (i.e.,  NTFS  versus  FAT  tables)  should  be  done  to 
ensure  a  smooth  transfer  of  files. 

Netware  4.1  is  being  evaluated  by  the  NCSC  according  to  the 
TNI  criterion  and  entered  into  the  final  evaluation  phase  in  August 
1995.  The  evaluation  is  covering  "both  the  Netware  4.1  code  and 
Cordant  Incorporated' s  Assure  bus-monitor  card  for  ISA-bus  systems 
and  is  designed  to  control  user  access  to  networks,  peripherals, 
and  local  memory."  [Ref .  32]  Cordant  is  also  working  on  a 
Fortezza  integration  with  this  card.  If  Netware  4 . 1  is  certified, 
it  will  be  the  first  network  operating  system  to  be  certified  for 
a  network  environment  according  to  the  TNI  criterion. 

Second,  the  incorporation  of  firewalls  is  recommended  for 
helping  to  ensure  the  confidentiality  of  sensitive  data.  Threats 
from  connecting  to  the  Internet  range  from  "curious  prowlers  to 
well -organized,  technically-knowledgeable  intruders  that  could  gain 
access  to  a  site's  private  information  or  interfere"  with  the 
availability  of  resources.  [Ref.  32]  During  the  past  decade, 
firewalls  have  become  a  popular  countermeasure  to  prevent 
unauthorized  access  from  external  sources. 

A  firewall  is  actually  a  collection  of  components  used  to 
protect  one  network  from  another  untrusted  network.  Because  the 
Internet  is  not  secure  and  provides  no  performance  guarantees, 
firewalls  are  typically  thought  of  for  accessing  the  Internet. 
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They  can,  however,  be  used  between  any  two  networks  where  one  is 
not  trusted.  The  purpose  of  the  firewall  is  to  provide  controlled 
access  to  both  internal  and  external  services.  Firewalls  are 
important  because  they  provide  a  single  "choke  point"  where 
security  and  auditing  features  may  be  provided. 

There  are  two  types  of  firewalls:  packet  filtering  gateways 
and  application  gateways.  The  packet  filtering  gateway  operates  at 
the  Transport  Layer  of  the  TCP/IP  architecture  and  simply  blocks  or 
filters  traffic  based  upon  the  address  and/or  protocol.  The 
application  gateway  operates  at  the  Application  Layer  of  the  TCP/IP 
architecture,  and  provides  a  more  specific  level  of  filtering. 

Packet  filtering  gateways  are  the  easiest  to  configure  and 
employ,  but  they  are  also  the  least  effective.  There  is  no  logging 
capability  on  a  packet  filtering  gateway,  so  it  is  difficult  to 
detect  if  and  when  an  intruder  has  corrupted  the  router.  This  type 
of  firewall  is  also  difficult  to  test  for  all  vulnerabilities, 
because  the  firewall  normally  permits  all  traffic  to  pass  unless 
specifically  denied.  If  an  intruder  does  break  through  the 
firewall,  the  host  becomes  directly  accessible  from  the  Internet. 
Finally,  a  firewall  which  depends  solely  on  address  filtering  can 
be  spoofed.  "Spoofing  is  an  attack  in  which  a  system  attempts  to 
illicitly  impersonate  another  system  by  using  its  IP  network 
address."  [Ref .  34] 

Application  gateways  are  more  secure,  because  they  are 
application  specific  and  have  auditing  capabilities.  They  are 
usually  combined  with  a  packet  filtering  gateway  and  add  another 
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security  filter  at  the  application  level.  Consequently,  an 
intruder's  packet  may  pass  through  the  initial  packet  filtering 
firewall,  but  it  will  not  have  direct  access  to  the  host  system  if 
it  is  also  required  to  go  through  an  application  firewall.  When  the 
packet  reaches  the  application  gateway,  the  gateway  checks  its 
access  matrices  and  grants  or  denies  access  to  the  requested 
application  or  service.  If  access  is  denied,  the  packets  are 
logged  and  dropped.  If  access  is  granted,  the  packets  are 
permitted  access  to  the  requested  application,  but  nothing  else. 
The  application  gateway  never  allows  access  to  the  host  system  and 
serves  as  a  proxy  for  the  requested  service.  It  is  very  secure 
because  it  allows  the  network  manager  to  control  who  has  access  to 
the  network  and  its  applications. 

There  is  a  false  sense  by  many  that  a  firewall  is  a  security 
panacea  for  Internet  security.  A  firewall,  like  any  security 
countermeasure,  is  not  the  end  all  solution,  but  rather  a  tool  to 
help  safeguard  system  resources.  The  following  security  guidance 
is  recommended  with  the  use  of  firewalls  on  the  Falcon  LAN: 


•  Components  which  permit  public  access  should  be  located 
outside  of  any  firewalls.  This  would  include  dial-in  modems 
and  WWW  servers . 

•  Install  a  packet  filtering  gateway  to  filter  out  unwanted 
guests  based  upon  their  address.  Behind  this  firewall  would 
reside  all  student  and  staff  accounts  with  the  data  widely 
available.  The  firewall  currently  resident  with  the  DLI 
CISCO  router  could  be  used  for  this  requirement,  but  modem 
access  behind  the  router  (internal  to  the  NSGD  LAN)  is 
discouraged.  Modems  provide  a  point  of  access  to  the  LAN, 
which  would  circumvent  the  firewall. 
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•  An  application  firewall  behind  the  first  firewall  should  be 
installed  to  separate  all  sensitive  data  (e.g.,  grades, 
clearance  information,  etc.)  from  the  rest. 

There  is  a  wide  range  of  firewall  products  available  today 
with  respect  to  both  quality  and  strength.  Routers  with  built-in 
packet  filtering  gateways  start  at  approximately  $3,000.  Most 
commercial  firewall  packages  range  from  approximately  $10,000  to 
over  $250,000  in  price.  "Home-grown"  firewalls  can  be  built  for 
considerably  less  money,  however,  building  a  firewall  requires  a 
significant  amount  of  skill  and  knowledge  of  the  TCP/IP 
architecture.  Regardless  of  the  type  of  firewall  selected,  it  will 
require  regular  maintenance,  installation  of  software  patches  and 
updates,  and  regular  monitoring. 

During  the  fall  of  1995,   the  National  Computer  Security 
Association  (NCSA)   organized  the  Firewall  Product  Developers' 
Consortium  (FWPD)  to  bring  major  vendors  of  firewall  products 
together.   "The  purpose  of  the  consortium  was  to  decrease  confusion 
about  computer  firewall  products,  enhance  quality,  provide  a  common 
terminology  and  testing  methodology,  and  improve  the  ease-of-use 
and  security  of  firewall  products."   [Ref .  35]   By  February  1996, 
the  consortium  had  developed  a  baseline  of  functions  that  firewall 
products  should  offer  and  procedures  to  certify  products  according 
to  performance  criteria.   The  performance  criteria  used  includes 
the  "ability  to  handle  90%  of  security  threats  based  on  the 
likelihood  of  attack  by  hackers,  ease  of  use  by  hackers,  and  how 
much  harm  could  be  done."   [Ref.  36]   Application- level  firewalls, 
in  particular,  are  tested  against  "approximately  120  types  of 
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network  attacks  and  must  resist  the  most  common  and  dangerous  ones 
in  order  to  earn  the  NCSA  certification.  The  tests  emphasize  the 
success  or  failure  of  the  firewall  against  intrusion  attempts,  not 
the  methods  by  which  such  attempts  are  blocked."  [Ref .  37]  The 
testing  process  does  not  stop  once  a  product  is  certified,  rather 
products  are  retested  at  least  once  per  quarter  to  address  changing 
business  needs  and  new  security  threats.  The  intent  of  the 
certification  program  is  to  provide  users  with  a  level  of  assurance 
that  the  firewall  will  provide  the  desired  protection  against 
existing  and  future  threats.  Participating  vendors  and  products 
that  have  been  certified  can  be  found  through  the  NCSA  home  page  at 
http://www.ncsa.com.  The  page  currently  has  16  certified  products 
listed  including  Borderware,  Checkpoint  Firewall-1,  AltaVista, 
IBM's  Secured  Network  Gateway,  Eagle,  Sunscreen  SPF-100,  and 
Gauntlet  Internet  Firewall  System.   [Ref.  38] 

C.    ADVANTAGES  AND  DISADVANTAGES  OF  THE  TCSEC 

Requiring  specific  levels  of  trust  for  the  military  computer 
systems  has  both  its  advantages  and  disadvantages.  The  major 
advantage  is  that  criteria  provide  a  common  basis  for  discourse. 
If  a  specific  level  of  trust  (e.g.,  Class  C2)  is  specified,  then 
users  are  guaranteed  a  system  with  at  least  the  features  and 
assurances  prescribed  by  the  TCSEC.  Without  some  well-defined 
criteria,  the  users  are  left  to  the  mercy  of  the  vendor's  marketing 
departments . 
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Other  major  advantages  include  an  increased  level  of  awareness 
given  to  computer  security,  an  overall  higher  level  of  assurance 
against  major  threats  to  most  systems,  and  a  range  of  more  secure 
products  available  to  DOD  activities.  As  the  National  Research 
Council  noted  in  1991: 

If  one  waits  until  a  threat  manifests  through  a 
successful  attack,  then  significant  damage  can  be  done 
before  an  effective  countermeasure  can  be  developed  and 
deployed.  Therefore,  countermeasure  engineering  must  be 
based  on  speculation.  Effort  may  be  expended  in 
countering  attacks  that  are  never  attempted.  The  need  to 
speculate  and  to  budget  resources  for  countermeasures 
also  implies  a  need  to  understand  what  it  is  that  should 
be  protected  and  why.   [Ref.  2:  p.  157] 

By  requiring  military  organizations  to  ensure  a  specified  level  of 
trust  for  their  operational  environment,  the  safeguards  will 
hopefully  be  in  place  when  an  attack  is  attempted.  The  control  of 
information  could  be  compared  to  the  need  for  sea  control. 
Numerous  resources  are  devoted  to  ensuring  the  proper  controls  are 
in  place  at  sea.  If  the  same  controls  were  not  in  place,  the 
resultant  costs  would  be  too  great  once  an  attack  had  occurred. 
Yet  when  it  comes  to  controlling  our  information,  too  many  systems 
have  been  implemented  with  little  or  no  regard  for  security  until 
a  compromise  has  occurred.  By  forcing  users  to  evaluate  security 
threats  and  countermeasures,  the  overall  security  of  the  system 
will  increase. 

On  the  other  hand,  requiring  a  specific  level  of  trust  is  not 
free.  The  added  life-cycle  costs  to  maintain  the  system  and 
monitor  the  security  features  are  increased  as  the  level  of  trust 
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increases.  Personnel  must  be  available,  trained,  and  dedicated  to 
their  jobs  to  ensure  the  security  features  of  the  hardware  and 
software  are  not  bypassed.  Audit  logs  in  particular,  require 
numerous  manhours  to  review.  In  addition,  the  purchase  price  of 
"trusted  systems"  will  tend  to  be  higher. 

Another  disadvantage  to  requiring  trusted  systems  is  the  lack 
of  availability  of  trusted  hardware  and  software.  To  have  a  system 
evaluated  by  the  NCSC  for  a  certain  level  of  trust  is  expensive 
both  in  terms  of  time  and  financial  support.  Most  evaluations 
require  years  to  complete,  and  many  vendors  are  reluctant  to 
initiate  an  evaluation  due  to  these  costs.  In  addition,  there  is 
an  overall  lack  of  products  certified  to  operate  in  a  networked 
environment,  which  describes  the  majority  of  systems  used  by  the 
military  today.  Until  the  benefits  from  having  a  product  certified 
outweigh  the  costs,  the  availability  of  certified  products  will 
remain  a  problem  for  many  organizations. 

Finally,  the  certification  and  accreditation  process  can  be 
quite  cumbersome  for  most  commands.  The  military  does  not 
currently  have  enough  personnel  adequately  trained  to  conduct  a 
thorough  system  certification  and  the  requirements  can  be 
confusing.  Although  using  a  certified  product  assists  with  the 
overall  procedure,  it  does  not  replace  the  requirement  to 
thoroughly  evaluate  the  system  for  its  operational  environment. 
Until  more  certified  products  are  available  and  personnel  receive 
the  appropriate  training,  many  commands  will  continue  to  struggle 
with  the  certification  and  accreditation  process. 
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D.    SUMMARY 

This  thesis  set  out  to  examine  the  current  applicability  of 
the  Class  C2  level  of  trust  in  a  typical  command  environment  using 
Windows  NT.  In  meeting  this  objective,  the  certification  and 
accreditation  requirements  had  to  be  closely  examined  as  well  as 
the  software  and  hardware  of  the  environment  selected.  Although 
the  commercial-off-the-shelf  products  are  getting  much  closer  to 
providing  an  avenue  for  achieving  the  desired  level  of  trust,  there 
is  still  much  progress  to  be  made.  Perhaps  in  the  future,  system 
administrators  will  be  able  to  walk  into  a  computer  store  and 
purchase  products  which  are  appropriate  for  the  security 
requirements  of  their  operational  environment.  Use  of  these 
products  will  not  eliminate  the  requirement  for  certification  and 
accreditation,  but  will  make  the  attainment  of  trusted  systems 
possible.  However,  until  that  day  arrives,  caution  must  be  given 
to  the  network  configurations  selected  to  meet  a  command's 
functional  requirements.  In  the  meantime,  the  widespread 
establishment  of  Class  C2  systems  throughout  the  military  remains 
on  the  road  ahead. 
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